[00:24] <ari-tczew> please universe sponsors for review bug 524912
[00:35] <sistpoty> ari-tczew: I'm inclined to follow randomaction's comment: There are no changes that we need right now, this only wastes time and bandwidth
[00:38] <ari-tczew> sistpoty: fakesynces for main too wastes time?
[00:38] <Laney> pointless uploads always waste time
[00:38] <sistpoty> ari-tczew: *if* these don't bring in changes then yes
[00:38] <jpds> (and CPU power, bandwidth, ...)
[00:39] <ari-tczew> great! all my time is wasted! love you!
[00:39] <sistpoty> not only the upload wastes time, everyone having the package installed will also need to download the new version for no benefit
[00:39] <crimsun> ari-tczew: don't feel bad. Your efforts are appreciated; it's just that fixes need to be significant from a certain point forward.
[00:40] <Laney> you should target your efforts where they will have more impact
[00:41] <ari-tczew> I'm merge-n00b, so I'm useless in FeatureFreeze
[00:42] <ari-tczew> hmmm recently someone told me that fakesyncs are welcome in FF
[00:42] <ari-tczew> and merges without new upstream release
[00:42] <ari-tczew> and today you tell me that this is wasting time!
[00:42] <ari-tczew> rofl
[00:43] <Laney> you need to zoom out a bit
[00:43] <lifeless> it depends on why the fakesync
[00:43] <Laney> and think about what the upload is supposed to achieve
[00:43] <sistpoty> ari-tczew: merges without new upstream release *are* welcome, but we don't need to include uploads that are semantically identical to what we have
[00:43] <lifeless> if there is a bugfix, and to do it 'right' you do a fakesync as part of that; then it fixes a bug
[00:44] <ari-tczew> love you again <3
[00:45] <paissad> guys, i'm trying to rebuild trac with a new snapshot from upstream, here is the log of debuild -us -uc --lintian-opts -iIEv --pedantic ---> http://pastebin.com/f121d8915 ..... but the problem is that i don't have the same structure in debian/trac/* as when i extract the created .deb package
[00:45] <paissad> here is the debian/trac tree --> http://pastebin.com/f40099b75
[00:45] <paissad> here is the structure when i extract the package (the deb file) --> http://pastebin.com/f36b9a83a
[00:46] <paissad> i don't understand !:/
[00:46] <ari-tczew> paissad: why you want to get new snapshot?
[00:46] <ari-tczew> is it fixes something?
[00:47] <paissad> ari-tczew, mostly in order to have the translations , but there are many new & interesting features too ^^
[00:47] <ari-tczew> paissad: no! there is FeatureFreeze!
[00:47] <ari-tczew> get out here!
[00:47] <paissad> ari-tczew, o0
[00:47] <sistpoty> ari-tczew: please calm down a bit
[00:48] <ari-tczew> sistpoty: I write just only true
[00:48] <paissad> ari-tczew, you're mad ?
[00:48] <ari-tczew> paissad: yes :D FeatureFreeze and generally policy drive me crazy
[00:49] <paissad> ari-tczew, then i think it's you who need to get out of here .... go see a psy mate !
[00:49] <paissad> well .. does somebody have any idea about my problem
[00:51] <crimsun> ari-tczew: please step back for a moment and realize that we're all just trying to prepare Lucid. You aren't being flamed. You aren't expected to know the policies immediately.
[00:52] <paissad> right, i've learning the policies for a month now & i still cannot finish my packaging because i after debhelper, maintainer-guide, i have to learn javahelper & debconf ^^ ... but that's not a reason to get crazy .. that's life
[00:52] <paissad> i've been*
[00:52] <Laney> paissad: how did you get to the new snapshot?
[00:53] <paissad> Laney, from svn
[00:53] <Laney> svn export?
[00:53] <paissad> svn export yes !
[00:53] <Laney> did you tar up the svn export and then uupdate with it?
[00:54] <paissad> Laney, yeah, i have a orig.tar.gz file created after svn export
[00:54] <Laney> maybe the build system changed somewhat
[00:54] <Laney> it might be an idea to just go with it unpackaged in /srv or whatever
[00:55] <asac> sistpoty: no we dont sync
[00:55] <ari-tczew> crimsun and other from team: easy man, slacken your tie!
[00:55] <geser> paissad: do you have a debian/trac.install or debian/install file?
[00:55] <asac> sistpoty: ok thats a misleading wording
[00:55] <asac> its just latest gnash
[00:55] <paissad> geser, no i don't have a debian/install or debian/trac.install
[00:55] <micahg> ari-tczew: we have xulrunner-1.9.2 in a PPA if you want to test build your package against it
[00:57] <paissad> geser, i did not created an install file because my debian/rule file handle it  http://pastebin.com/f3a5c4835
[00:57] <ari-tczew> micahg: great! but I don't know... there's feature freeze and ... :/
[00:57] <micahg> ari-tczew: which package is it?
[00:59] <cody-somerville> I just got a bunch of bug mail due to activity by Marco Rodrigues. I thought he was asked to abstain from participating.
[00:59] <geser> paissad: I guess I understand why. your package uses an old debhelper version which used debian/tmp for staging while you install to debian/trac for staging
[01:00] <sistpoty> asac: thanks for looking :)
[01:00] <paissad> geser, and then,what must i do ?
[01:01] <paissad> i saw that warning " debhelper version lower than 5 ****" but i did not understand ... that's what i said
[01:01] <sistpoty> cody-somerville: afaict that's still true... did his behavior increase at least?
[01:01] <geser> either update the debhelper version (as lintian suggest anyway) or "install" to debian/tmp too
[01:02] <ari-tczew> micahg: libjdic-java
[01:02] <micahg> ari-tczew: yeah, that's on the list, so go ahead, here's the PPA to set as a dependency: https://launchpad.net/~mozillateam/+archive/ffox35
[01:04] <paissad> geser, debhelper                7.4.15
[01:06] <geser> paissad: you need to tell which debhelper compat version your package needs (see the value in debian/compat)
[01:06] <cody-somerville> sistpoty, He added add bug tasks for the startup-manager project in launchpad to bugs against the startupmanager source package - even for bugs that are already Fix Released.
[01:07] <Laney> well he was asked by the MC to stop participating, right?
[01:07] <sistpoty> cody-somerville: *sigh*
[01:07] <Laney> so really I doubt they have jurisdiction over the whole of LP...
[01:07] <cody-somerville> sistpoty, It doesn't look like he actually confirmed if they were upstream bugs or not either.
[01:08] <paissad> geser, you got it mate, you got it ^^ .... i would never find it by myself ... i thought that debian/compat was not so important
[01:08] <paissad> geser, thanks for all
[01:09] <ari-tczew> micahg: can I use reason like 'transition for xulrunner -> 1.9.2' for FFe merge libjdic-java?
[01:10] <micahg> ari-tczew: make sure it builds first, then worry about FFe, but yes, that works
[01:10] <Laney> bugfixes don't need FFe
[01:11] <jdong> *looks at clock*
[01:11] <jdong> did I really just spend the last 11 minutes trying to make the emacs doctor say a sexual innuendo?
[01:11] <jdong> *goes back to being productive*
[01:11] <Laney> actually, I don't know if that's true for this cycle
[01:11] <sistpoty> !jdong
[01:11] <jdong> I think that factoid is gone :)
[01:11] <sistpoty> damn :P
[01:12] <jdong> :)
[01:13] <Laney> crimsun: I just made this if you want to do any uploads
[01:13] <Laney> http://orangesquash.org.uk/~laney/graph.png
[01:14] <Laney> (looks daunting when zoomed out)
[01:15] <micahg> ari-tczew: please subscribe myself and asac to the FFe bug
[01:15] <ari-tczew> micahg: sure! but give me a time for test
[01:15] <micahg> oh wait...no FFe needed :)
[01:15] <micahg> ari-tczew: yeah, I actually test built it in the PPA it seems to build ok
[01:16] <sistpoty> Laney: damn, there's too much red and too few green in there :P
[01:16] <ari-tczew> micahg: I don't know! here is FFe needed for live ; btw. currect Ubuntu's delta works, but Debian's revision doesn't work
[01:17] <Laney> sistpoty: yes indeed, this is the fun of a Haskell transition
[01:17] <Laney> luckily it should be completely solved by syncing
[01:17] <micahg> ari-tczew: FFe is needed is it's new features not bug fix per above
[01:17] <micahg> *if it's
[01:19] <sistpoty> Laney: do we need to sync in order, or will packages land in depwait nowadays?
[01:20] <sistpoty> (or just ftbfs, which just needs more manual intervention, but wouldn't restrict to sync out of order)
[01:20] <Laney> at least for this first round we need to sync in order
[01:21] <sistpoty> Laney: ok, thanks
[01:22] <Laney> debian has the edge here because they can issue nmu and dw commands to wanna-build easily
[01:25] <Laney> actually you probably could just sync everything straight away
[01:25] <ari-tczew> sistpoty: could you destroy my work too here? bug 512430 ; bug 524955 ; bug 524957
[01:25] <Laney> if soyuz had bd-uninstallable then it would be nicer
[01:28] <sistpoty> Laney: oh, so b-d's won't be installable if we sync out of order?
[01:28] <Laney> that's right, which is an FTBFS in soyuz
[01:29] <sistpoty> Laney: that's at least cool, because we then can click on retry and sync out of order :)
[01:29] <Laney> well I'm not sure that this gains anything
[01:30] <Laney> as james_w has said that I can bother him with lists of stuff to sync ;)
[01:30] <sistpoty> heh
[01:31] <Laney> last time we did this for (I think) ppc, as the world was broken there for a number of weeks
[01:31] <Laney> we just threw all of the FTBFS against the wall multiple times until it all went green
[01:31] <Laney> bit of a waste of buildd time though
[01:34] <ari-tczew> how can I add PPA into pbuilder list?
[01:34] <sistpoty> well, only ia64 and sparc are busy, so ... :)
[01:34] <Laney> heh
[01:34] <sistpoty> ari-tczew: pbuilder login --save-after-login
[01:34] <sistpoty> ari-tczew: then modify /etc/apt/sources.list and add the ppa
[01:35] <Laney> i'll start syncing stuff tomorrow after ghc6 is built in more places
[01:35] <Laney> for now, nn
[01:36] <ari-tczew> sistpoty: heh, but how can I edit file? nano doesn't work
[01:36] <sistpoty> ari-tczew: just from a glimpse at geronimo-jpa-3.0-spec, this does contain visible changes (e.g. the description), so that's not wasted work
[01:36] <ari-tczew> impossible!
[01:36] <sistpoty> ari-tczew: pbuilder should tell you a directory where the build chroot is extracted (right at the beginning)
[01:37] <sistpoty> ari-tczew: just use your favorite editor in the real system in that directory (and there etc/apt/sources.list)
[01:38] <ari-tczew> sistpoty: I don't understand. where's the right file?
[01:39] <Daviey> Hey, What is the highest quilt format supported by karmic?
[01:39] <persia> Daviey: Could you rephrase, or provide more context?
[01:39] <sistpoty> ari-tczew: pbuilder --login tells me:
[01:39] <sistpoty> ari-tczew: File extracted to: /var/cache/pbuilder/build//21606
[01:40] <sistpoty> ari-tczew: so that would be /var/cache/pbuilder/build/21606/etc/apt/sources.list for me right now
[01:40] <ari-tczew> ahh, okay, I'll check
[01:40] <Daviey> persia: sorry, debian/source/format = "3.0 (quilt)", however the lp ppa builders are complainign that version 3.0 isn't supported on karmic.  So what is the highest version that can be used
[01:41] <persia> Daviey: That's the source format :)  If you can unpack a source on karmic, and LP won't build it, that's an LP bug.
[01:41] <persia> I know there are some bugs in 3.0(quilt) that weren't resolved until lucid though.
[01:41]  * Daviey cries.
[01:42] <persia> Most people generally downgrade to 1.0: 2.0 has weak support in lots of tools.
[01:42] <sistpoty> I thought 2.0 never made it? only 3.0?
[01:42] <persia> sistpoty: 2.0 has some support in some tools in an almost entirely untested way :)
[01:43] <sistpoty> heh :)
[01:43] <Daviey> there does seem to be perl support for 2.0
[01:43]  * Daviey is embarrassed to commit http://pastebin.com/d1a11f4f7
[01:48] <persia> Daviey: Um, that doesn't accomplish ehat you hope.
[01:48] <persia> There is no Format: 1.0 (quilt).
[01:48]  * Daviey cries louder
[01:49] <persia> The way to do quilt with Format 1.0 is to build-dep on quilt, include a fragment in debian/rules (or use dh --with quilt), and put the patches in debian/patches
[01:49] <Daviey> yeah, i know that! :o
[01:50] <persia> Daviey: What are you trying to accomplish?  This may be an easier way to solve your issue.
[01:50] <ari-tczew> sistpoty: how can I fix it? W: GPG error: http://ppa.launchpad.net lucid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9BDB3D89CE49EC21
[01:50] <ari-tczew> in pbuilder
[01:51] <Daviey> persia: ok..  Have mythtv build scripts that auto build source packages for upstream trunk and a -fixes branch, for karmic and lucid.  For trunk packaging we've just moved over to quilt 3.0, and expected it to "just work" with karmic.  It hasn't.
[01:52] <Daviey> and incidently version 3.0 doesn't auto pop after a debuild.. I sort of expected it to.
[01:53] <sistpoty> ari-tczew: there's an apt setting to allow untrusted sources, but I've forgotten the details, sorry
[01:53] <ari-tczew> maybe someone else can fix it in pbuilder
[01:53] <ari-tczew> ?
[01:53] <geser> or you could add the key
[01:54] <persia> Daviey: Either backport dpkg to the environment you're targeting, or don't switch to Format 3.0
[01:54] <persia> Daviey: I don't think you can have single-source 3.0 that works in both environments properly with karmic dpkg, except for some subset of 3.0 packages.
[01:55] <Daviey> persia: yeah, i think backporting is a non-starter because LP PPA will still refuse the karmic package.
[01:56] <Daviey> i think i'll have to do quilt the old way for karmic packages.. but atm i'm thinking sleep.  Thanks for your help persia
[01:57] <persia> Daviey: How is it refusing it?  At what point?  I suspect that's a bug in LP that can be fixed, because if you backport/patch dpkg to behave differently, it should allow that.
[01:57] <persia> Sleep well :)
[01:57] <Daviey> persia: Rejected:
[01:57] <Daviey> myththemes_0.23.0~trunk23578-0ubuntu0~mythbuntu1.dsc: format '3.0 (quilt)' is not permitted in karmic.
[01:57] <ari-tczew> geser: pbuilder is calling to my home dir
[01:57] <ari-tczew> and it can't add gpg key
[01:58] <Daviey> persia: ^^ that is the PPA email following dput.  But i really must sleep. nn
[01:58] <persia> Daviey: Yeah, I'd call that a bug in launchpad :)
[01:58] <Daviey> >:(
[01:59] <sistpoty> ari-tczew: you could try that, not too sure if I recall it right though: echo "APT::Get::AllowUnauthenticated 1; " >> /etc/apt/apt.conf.d/allow-unauthenticated
[01:59] <sistpoty> ari-tczew: (inside the pbuilder chroot)
[02:01] <ari-tczew> :O
[02:01] <geser> ari-tczew: "apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9BDB3D89CE49EC21" inside your pbuilder
[02:02] <geser> sistpoty: why go the way through "allow unauthenticated" when only the PPA key is missing?
[02:08] <sistpoty> geser: you've got a point there
[02:08] <ari-tczew> geser: thanks!
[04:21] <sistpoty> persia: please unsubscribe u-u-s from bug #402874 (restricted), bug #524982 (already ack'd), bug #503111 (uploaded to proposed, awaiting moderation) thanks!
[04:22] <sistpoty> persia: or add me to u-u-s, then I can unsubscribe the team, whatever you prefer ;)
[04:22]  * persia adds
[04:23] <persia> sistpoty: Welcome to u-u-s.  I've also unsubscribed the bugs.
[04:23] <sistpoty> persia: thanks!
[04:23] <persia> Down to 10!  Wow.
[04:24]  * persia takes a loot at 507740 and 507741, being related.
[04:24] <persia> s/ot/ok/
[04:24]  * hyperair wonders when he can begin sponsoring things.
[04:24] <sistpoty> persia: make that 9, just uploading 480553
[04:25] <persia> hyperair: If it's not sorted by Tuesday, I'll ask at the TB meeting.
[04:25] <persia> hyperair: *soon* :)
[04:25] <hyperair> yay thanks =)
[04:25]  * persia wonders if we can clear the queue this weekend
[04:25] <zooko> Folks: just so you know there is a bug in Tahoe-LAFS v1.6.0 so we are working on releasing Tahoe-LAFS v1.6.1, ETA tomorrow.
[04:26] <persia> zooko: 1.6.1 is just a bugfix to 1.6.0 ?
[04:26] <sistpoty> oh, and bug #463019 needs input from patch author (or another one to eyeball the patch, as I've been a little bit slacky)
[04:26] <zooko> persia: yes
[04:26] <zooko> http://allmydata.org/trac/tahoe-lafs/query?status=assigned&status=new&status=reopened&group=status&milestone=1.6.1
[04:27] <persia> zooko: Excellent.  Thanks for so closely working with our release schedule and freezes.  It really helps to make sure we deliver quality software.
[04:27] <zooko> Likewise! :-)
[04:28] <sistpoty> and bug #511864 needs another ack from iulian, nhandler or ScottK
[04:28] <persia> sistpoty: I thought we were going with single-ack from ubuntu-release this cycle?  Am I not understanding the mail thread?
[04:29] <persia> or do I misremember you being a release team member?
[04:29] <sistpoty> persia: until there's consensus about the new policy, we'll be holding the status quo to not block current freeze exception requests
[04:30] <persia> Makes sense.
[04:31] <persia> How is that consensus confirmed?  For MOTU, we'd do that with a MOTU meeting, but I'm not sure of the context for confirming it for everyone.  TB meeting?  Release meeting?
[04:31]  * persia grumbles at bzr branches for packaging making it take extra long to download stuff for sponsoring.
[04:31] <sistpoty> persia: for MOTU we've switched to ML w.o. objections actually
[04:32] <persia> When did that happen?
[04:32] <hyperair> imo debdiffs ftw
[04:32] <persia> Last I knew we had a complicated sheaparding procss.
[04:32] <sistpoty> persia: some time ago already, let me dig the thread
[04:32] <persia> hyperair: Well, even debdiffs can't express everything.  I had a package sponsored last week where my changes couldn't all be expressed by debdiff, and the upload didn't actually do everything mentioned in the changelog.
[04:33] <hyperair> persia: what changes were they?
[04:33] <hyperair> then upload a debian.tar.gz. simple enough =\
[04:33] <persia> hyperair: Actually uploading an orig.tar.gz as part of the package :)
[04:33] <persia> No, that wouldn't address some classes of thing.
[04:33] <hyperair> =\
[04:33] <hyperair> then upload the whole .dsc if necessary
[04:33] <hyperair> or stick it up a PPA
[04:34] <persia> That wouldn't do it either.
[04:34] <hyperair> that's what i've been doing
[04:34] <hyperair> what wouldn't it address?
[04:34] <hyperair> i don't see any more problems
[04:34] <persia> PPAs just really complicate things.  We know that a package compiled in a PPA differs from a package compiled int he archive, so they shouldn't have the same version number, or we can't know what binary gets installed on user systems.
[04:34] <sistpoty> persia: thread at https://lists.ubuntu.com/archives/ubuntu-motu/2008-June/004069.html  (googled an arbitrary mail though, might want to see the full thread)
[04:34] <persia> Plus, it wastes bandwidth.
[04:35] <hyperair> persia: and bzr doesn't?
[04:35] <persia> sistpoty: That's the thread that ended up bringing forward the complicated sheparding process.
[04:35] <hyperair> persia: imo if i've an orig tarball already, i don't want to download the entire unpacked contents of the tarball again just to sponsor
[04:36] <sistpoty> persia: yes, do I recall it right that the consensus was to try it out and see if it works? (and that status was imho never changed afterwards)
[04:36] <persia> hyperair: Sure, but 1) dget and apt-get source already don't do that, and 2) I don't think I've ever personally encountered that situation.
[04:36] <persia> sistpoty: It was declared to work when used a few times, and then MOTU meetings were suspended, and we never resolved to not do it that way.
[04:37] <hyperair> persia: a non new-upstream release sponsor should allow you to get the orig tarball from your local mirror
[04:37] <persia> But now that we have the new shiny MOTU (wgrant put it best at UDS Jaunty "MOTU Is dead, long live MOTU"), we can do things entirely differently :)
[04:37] <hyperair> which is very much faster than launchpad
[04:38] <persia> hyperair: I never meant to indicate that uploading everything to LP was a good idea.  I spent an immense amount of time writing tools that would automatically generate packages from diff.gz files to avoid precisely that a number of years ago (which bitrotted, and are now completely obsolete).
[04:38] <sistpoty> persia: maybe we should do a motu meeting again (though this time I won't try to organize it, due to the epic failure for my last try *g*)
[04:38] <persia> I just don't like having to download the source *twice* to get the orig.tar.gz *and* the bzr branch.
[04:39] <persia> sistpoty: Indeed, although I think there are two or three threads that need to happen on the mailing list before it's pointful.
[04:39] <persia> sabdfl has indicated he'd like to attend the next MOTU meeting, as well.
[04:40] <sistpoty> persia: however -release practices aren't really matter to motu policies imho, how motu-release came to a decision (be it one or two acks, having delegates or not) was imho a decision of motu-release and was handled that way
[04:41] <persia> Yes, but it was a MOTU meeting that specifically delegated process decision to motu-release.
[04:41] <persia> But none of this matters, because motu-release is no more (or should be shortly)
[04:41] <sistpoty> persia: oh, didn't recall that *g*
[04:41] <persia> Which is a truly good thing, in my opinion :)
[04:41] <sistpoty> *nod*
[04:41] <persia> sistpoty: You only came to 1/3 of MOTU meetings :p
[04:41] <sistpoty> haha
[04:42] <hyperair> persia: well if it were maintained i think it would save a lot of bandwidth and time.
[04:42] <hyperair> persia: unless launchpad were to get mirrors around the world.
[04:42] <persia> What?
[04:42] <hyperair> persia: the tools that generate packages from diff.gz files
[04:43] <persia> Not really.  It's always faster to use a dsc on a local mirror.
[04:43] <persia> The tools relied on watch files, get-orig-source rules, etc.
[04:43] <sistpoty> persia: btw, my feeling is that a posts like "that's my suggestion of the new policy", "I'm ok with it", "let's make it so, anyone who has objections, please speak up" should give us a proper base for the new -release policy, granted that it's not done in 1 day
[04:44] <persia> sistpoty: I think that gives us a good basis for a policy.  I'd like to see that given some official imprimatur, which might just be that it gets an [AGREED] in a release meeting.
[04:44] <persia> That makes it show up on u-d-a, and what not.
[04:44] <persia> This is a good thing because it helps address the issue of people feeling like policy is changing and they can't keep up.
[04:45] <sistpoty> persia: good point, once the policy proposal is agreed on, I'll try to get it routed to the proper channels and have it agreed on (probably asking you again, what you think the proper channels are *g*)
[04:45]  * persia gives up on using bzr again, after being told that a branch that works from loggerhead doesn't work for bzr merge
[04:48] <kamalmostafa> persia: thanks for taking on the libti* pair.  if i've completely botched it, i'm available for punches in the nose.  ;-)
[04:49] <persia> kamalmostafa: Did you botch it?  I can't tell yet, and given the format of things, expect it to be some time before I manage to actually figure out what diff you want sponsored.
[04:50] <persia> For some reason, the sequence `bzr branch lp:ubuntu/lucid/libticalcs; cd libticalcs; bzr mergelp:~kamalmostafa/ubuntu/lucid/libticalcs/merge-507740` tells me of an invalid branch, so I'm kinda digging through files individually based on timestamps (because I'd like this fixed).
[04:50] <persia> IF you'd like to toss me a couple debdiffs, it'd make it easier for me :)
[04:52] <kamalmostafa> persia: Well, I don't *think* I botched it really -- and I have no idea what's going on with bzr there (but I normally stick to branch and pull -- merge scares the heck out of me ;-).  I'll happily send you debdiffs instead.  Should I attach them to the bugs?
[04:52] <persia> That's probably easiest :)
[04:52] <persia> Well, without merge, I have no idea how I'd get your intended content into the target branch.
[04:53] <persia> I suppose I could use push --overwrite, but that probably breaks the importer.
[04:53] <persia> Easier to just do it the old way, which I know works, and let the importer work or break as it likes.
[04:53] <kamalmostafa> persia: ok, it'll take me a few minutes to dig up the trees here and generate debdiffs.  I'll holler for you.
[04:54] <sistpoty> persia, kamalmostafa: oh, libti* is on my radar as well, I was just hesitant to look at it. do we need a transition for that?
[04:55] <persia> kamalmostafa: Don't worry about libticalcs: I think I got that one.  Just getting a debdiff for libtifiles would make the second one faster.
[04:55] <kamalmostafa> persia: got it
[04:55] <persia> sistpoty: We need a couple removals, but kamalmostafa suggests the removals should happen *after* the merges.
[04:56] <kamalmostafa> but note... kamalmostafa quite likely is clueless about the proper flow here.  :-)  that was just my interpretation of ScottK's wishes
[04:56] <sistpoty> persia: /me thought there's a library name change involved, correct or did I misread things? (I really didn't look too close yet)
[04:57] <persia> sistpoty: two different source names for the same package, with two entirely different histories.
[04:57] <sistpoty> persia: ah, then I obviously misread :)
[04:57] <persia> kamalmostafa: I *think* http://paste.ubuntu.com/380765/ is right.  Let me know if you see anything obviously missing.
[04:58]  * kamalmostafa takes a "quick look" at that 1600-line pastebin!
[04:58] <persia> heh
[04:59] <persia> pull it, and use lsdiff : I know the changes for each file match your branch, but I just wanted to make sure I caught all the files.
[05:03] <kamalmostafa> persia: regarding libtifiles (which is a much smaller piece of diff) -- isn't the diff you're looking for actually already available via launchpad?:  https://launchpadlibrarian.net/39077715/eAxA2dm70kBMstFYzoeFWOafsxN.txt
[05:04] <persia> That is what I want.  Where's that link?
[05:05]  * persia may suddenly be not at all unhappy about bzr branches on bugs again
[05:05] <kamalmostafa> On the bug page (or the merge proposal, or the branch, I think):  https://bugs.launchpad.net/ubuntu/+source/libticalcs/+bug/507741    The green text in the "Related branches" block
[05:08] <persia> kamalmostafa: Aha.  I missed that the "Diff: 116 lines" bit was actually a clickable link to some javascrpt that gave me yet another link to actual output.  Thanks!
[05:08]  * persia grabs the real diff for libticalcs, and reapplies
[05:11]  * persia really appreciates all the effort that has gone into making sure the two alternate workflows don't block each other, and can be transposed at any step in the process.
[05:13] <kamalmostafa> persia: well, it sounds like it doesn't matter now, but fwiw, yes, I confirm that your pastebin diff does hit exactly the same files as I uploaded.
[05:13] <persia> Doesn't matter at all, and I've disposed of the packages that I used to generate that diff :)
[05:14] <persia> But I'm a little confused about libtifiles: the upstream version appears to have changed.
[05:14] <persia> Should I be using the ubuntu libtifiles2 tarball?
[05:17] <kamalmostafa> I don't know (again, the actual merge process is quite foreign to me -- you folks always "just take care of it" :-)
[05:17] <persia> kamalmostafa: OK.  Let me ask that differently.  What tarball did you use for your local libtifiles package?
[05:18] <kamalmostafa> persia: checking here
[05:20] <kamalmostafa> persia: I started with the "bzr branch lp:ubuntu/libtifiles" tree, then merged in the ubuntu-changes from the bzr libtifiles2 tree.  (so I didn't manually collect any tarball).
[05:21] <persia> OK.  Did you build a source package?
[05:21] <kamalmostafa> yes
[05:21] <persia> And there was a tarball as part of that source package?
[05:22] <kamalmostafa> certainly -- the orig tarball (maybe this is what you wanted):  libtifiles_1.1.1.orig.tar.gz
[05:22] <RAOF> If you're not familiar with it, bzr builddeb can recreate an orig.tar.gz from the package branch + the pristine-tar data that I think is stored in a revision property.
[05:23] <persia> kamalmostafa: OK.  Then there's an issue: the changelog calls for a orig tarball for a version that doesn't match the provided tarball.  I can't build that package.
[05:23] <persia> Or rather, I can't upload that package.
[05:24] <persia> RAOF: That's a really cool feature.  Would it be able to override the standard naming conventions?  If so, is this a bug?
[05:25] <kamalmostafa> I remember discussing this with ScottK -- the oddity of the "version number jump", which he seemed to think was the right thing to do
[05:25] <kamalmostafa> but I certainly can't say that I know how we should proceed here
[05:25] <RAOF> persia: I don't know.  When I've used it, it has Just Worked™.  You'll probably get more joy out of james_w :).
[05:26] <persia> RAOF: My fear there is that I'll end up in a learning session, and at the end be much more knowledgeable and much wiser, and have lost track of my original query :)
[05:26] <persia> kamalmostafa: OK.  So, I agree with ScottK that we want to base off 1.1.2, because that's the version we have for libtifiles2, but I'm not convinced you've actually done this.
[05:27] <persia> kamalmostafa: Please tey building a package with the 1.1.2 tarball, and test it, etc.
[05:27] <persia> s/tey/try/
[05:27] <RAOF> persia: :).  I'll have a look at the package branch, shall I?  Maybe I'll spot something obvious.
[05:28] <persia> RAOF: If you're familiar with the code, sure.  Either way, I have strong doubts that this merge was tested: my concern is mostly that we don't end up with lots more cases like this (although the specific situation should be rare enough to not happen often).
[05:30] <kamalmostafa> persia: actually, now that I look more carefully at the _source.changes file, it appears that this actually *was* based off of 1.1.2
[05:30] <persia> So you did test against the 1.1.2 tarball?
[05:31] <persia> Could you pastebin everything but the signature on your source.changes?
[05:31] <kamalmostafa> persia: you keep referring to "the ... tarball" -- but remember that I did all of this work using bzr, not tarballs.
[05:31] <persia> (the reason not to paste the signature is that it acts as a token, so that someone else could perfom an action with that .changes file pretending to be you)
[05:32] <persia> kamalmostafa: Sure, but the source package shouldn't care.  The .changes file and .dsc file should be tracking a tarball.
[05:32] <persia> That you happened to use bzr as a workflow aid should be completely immaterial.
[05:32] <persia> Otherwise there is a bug in bzr-buildpackage.
[05:33] <persia> (technically, with the new source package formats, it might be a zip file or lha archive or some other such collection, but that's mostly irrelevant, and I'll keep calling them tarballs anyway)
[05:34] <kamalmostafa> persia: http://pastebin.ubuntu.com/380779/
[05:36] <persia> OK.  Next bit is tricky: we have to figure out how you constructed libtifiles_1.1.2.orig.tar.gz
[05:37] <kamalmostafa> persia: so I actually did all this work like 5 weeks ago, but its all starting to come back to me....
[05:37] <persia> Because the checksums don't match the libtifiles2 tarball, and there's no watch file or get-orig-source rule.
[05:37] <persia> Any ideas?
[05:37] <kamalmostafa> I think "bzr builddeb -S" must have constructed it for me.
[05:37] <kamalmostafa> (or download it for me)
[05:37] <persia> Any idea what source it might have used to do so?
[05:37] <kamalmostafa> Yes, the "libtifiles2" source
[05:38] <persia> patched or unpatched?
[05:38] <kamalmostafa> ... what was coming back to me was...  there was actually only one tiny code change, I think between libtifiles2 and libtifiles (fwiw) -- src/comments.c.
[05:38] <kamalmostafa> I don't know the answer to "patched or unpatched".
[05:39] <persia> Right.
[05:39] <persia> So, I'm going to disregard that file as locally constructed from unknown sources.
[05:40] <persia> Now, let's see if we can find a trustable file.  debian/copyright suggets that it can be downloaded from http://lpg.ticalc.org/prj_tilp/
[05:41] <kamalmostafa> persia: are we talking about: libtifiles2_1.1.2.orig.tar.gz ?   apt-get source libtifiles2  fetches a matching tarball to the one I have locally here.
[05:42] <persia> kamalmostafa: I'm talking about what to use for libtifiles_1.1.2.orig.tar.gz
[05:42] <persia> libtifiles2-1.1.2.tar.gz provided by upstream has matching checksums to libtifiles2_1.1.2.orig.tar.gz from the archive.
[05:43] <persia> So I trust that the libtifiles2 1.1.2 package in the archive has the right tarball.
[05:43] <persia> Does the content of that tarball match the content of your locally constructed libtifiles_1.1.2.orig.tar.gz ?
[05:44] <kamalmostafa> I can check that -- are we working under the reasoning that bzr somehow contstructed it for me automagically, and that it should match then?
[05:44] <kamalmostafa> * that it's contents should match then?
[05:44] <persia> That's my assumption
[05:45] <persia> I don't trust your tarball because I can't be sure it matches upstream, but I'm hoping that it does, because otherwise there's more work to the merge.
[05:50] <kamalmostafa> persia: they don't match -- but it looks like the delta is all auto-generated files (that bzr builddeb -S may have removed when it constructed this tarball?):  http://pastebin.ubuntu.com/380786/
[05:50] <persia> kamalmostafa: OK.  So, now create and test your package using the upstream tarball, and let me know if it still works.
[05:51] <persia> I suspect the difference is a call to make clean or similar.
[05:51] <kamalmostafa> persia: yes, that's exactly what I am thinking
[05:53] <persia> kamalmostafa: Also, please file a bug on bzr-buildpackage: it should be providing a sufficiently obvious warning when doing this that someone will be inclined to go check.
[05:53] <persia> It would be unfortunate if at the time we finally get support for arbitrary archive formats we end up doing something that causes us to lose the ability to trust package-provided archives.
[05:56] <RAOF> kamalmostafa: I think that you might have been meant to use “bzr merge-upstream” on the 1.1.2 tarball before doing the rest of the work.
[05:58] <persia> RAOF: The trick being that it wasn't clear that it was a new upstream, because the merge was between two different source packages (due to some unfortunate history).
[05:58] <RAOF> Aaah.
[05:58] <persia> But bzr-buildpackage should still warn users when it *constructs* an artifact and calls it *orig*
[05:59] <persia> Err, that would have been clearer has I used /constructs/ rather than *constructs*
[05:59] <persia> s/has/had/
[05:59]  * persia gives up
[06:00] <kamalmostafa> persia: I'd prefer that you file the bug report against bzr-buildpackage -- your understanding of the issue is *much* clearer than mine here.  :-)
[06:01] <persia> Well, except I've never experienced it, and don't know how to create a situation where it would occur :)
[06:02] <persia> I only get annoyed when recommended workflows break trust paths for artifacts.
[06:03] <kamalmostafa> persia: fair enough -- but I've only "experienced it" because you're telling me that I have, and I don't know how I created the situation either!  ;-)   Let me try to recreate it and we'll see if we can get a clearer handle on the issue.   (Actually, it sounds like RAOF may have a better understanding of all of this!)
[06:04] <persia> kamalmostafa: Do you understand why it matters that I know how to construct your tarball from trusted sources?
[06:04] <kamalmostafa> persia: oh yes, certainly!
[06:04] <persia> (or what I mean by "trusted sources"?)
[06:04] <persia> Oh, good :)
[06:04] <kamalmostafa> oh yes
[06:07] <kamalmostafa> persia: okay, you'll be happy...  I disposed of my local copies of libtifiles_1.1.2.orig.tar.gz, and tried "bzr builddeb -S" again, and it fails, yielding:
[06:07] <kamalmostafa>    bzr: ERROR: Unable to find the needed upstream tarball: libtifiles_1.1.2.orig.tar.gz.
[06:07] <kamalmostafa> So how the heck did I get around that 5 weeks ago.  RAOF, what was the deal with that option you were talking about there?
[06:08] <kamalmostafa> persia: so no bug to file against bzr, I think.
[06:08] <persia> Excellent!
[06:08] <persia> Of course, this doesn't explain how you ended up with the file :)
[06:10] <kamalmostafa> *sigh* I knew it was a mistake letting this one sit in the queue for five weeks!  ;-)   shaking off more cobwebs...  examining "bzr help builddeb"...
[06:11] <kamalmostafa> Ah, here it is.  Yes, I now remember using:   bzr builddeb --export-upstream={something}    But what was the something?
[06:13] <persia> By the way, I get "unrepresentable changes to source" if I apply your patch to libtifiles-1.1.1-1 and try to build against libtifiles2_1.1.2.orig.tar.gz
[06:20] <persia> kamalmostafa: Also, if you had to intentionally run --export-upstream, then I don't think there's a bug in bzr-builddeb that needs investigation.  There may be a documentation issue that you were instructed to run this, but that's minor.
[06:20] <kamalmostafa> persia: okay, forget my comment about --export-upstream.  Here's what I did (I can recreate it now):    bzr builddeb -S --split
[06:21] <RAOF> Hah.  Yes.  --split generates the orig.tar.gz from the branch.
[06:21] <kamalmostafa> what possessed me to use --split?    I imagine that it was "Hey, it works!  Must be right!"  Doh.
[06:23] <persia> Is there any warning in the --split documentation that this may not be a good idea, or suggesting watch files or get-orig-source rules?
[06:23] <kamalmostafa> Obviously not enough to have caught my eye.  :-(
[06:25] <RAOF> There isn't any warning on --split, no.
[06:26] <persia> I wonder how it might be phrased.  Obviously, for some developer working on their own code and preparing test packages, it shouldn't break anything, or it's just annoying, but for a developer working on a distribution, it should be fairly clear and point them in the right direction.
[06:28] <persia> And, actually, for an upstream developer, it might be a very handy tool to generate tarballs for general release in the first place.
[06:30] <RAOF> “bzr export” would probably be better for them, I think.
[06:31] <kamalmostafa> is there a proper way to tell "bzr builddeb -S" to use a particular filename as the upstream tarball (or is it acceptable for me to just copy the .orig.tar.gz to the name I know bzr will look for)?
[06:31] <persia> Or `bzr tarball` to combine that with construction and compression in a checksum-safe way.
[06:31] <persia> kamalmostafa: bzr isn't the bit that cares: it's dpkg-source (which is called by bzr builddeb).  You can just rename the file.
[06:33] <kamalmostafa> persia: okay, I've caught up to where you were 15 minutes ago... I now also get unrepresentable changes (fr.gmo) when I try to build my source package against libtifiles2_1.1.2.orig.tar.gz.
[06:34] <persia> Hmmm..  It doesn't seem to print any output with --split (based on upstream.py:285-298.  Is there somewhere else that prints output that I'm missing?
[06:34] <persia> kamalmostafa: OK, so we can't upload that :)
[06:35] <persia> kamalmostafa: If you know how to construct fr.gmo, delete it on clean, and construct it during the build.  This works around the issue.
[06:35] <kamalmostafa> does it belong in the source package at all?
[06:36] <persia> Due to a decision about how dpkg should work, we can't actually delete anything without breaking the tarball.
[06:36] <persia> But since it's changed, and probably related to an intentional change to fr.po, we need to make sure it's reconstructed properly.
[06:37] <kamalmostafa> yes, I do remember merging a change to fr.po
[06:37] <kamalmostafa> okay, let me see what happens if I dispose of it in clean here.
[06:37] <persia> Or alternately, we could just not change it.
[06:38] <kamalmostafa> you mean leave out the fr.po change?
[06:38] <persia> No, the fr.gmo change.
[06:38] <persia> If it is overwritten on build, we can just use the one from upstream as a base.
[06:38] <kamalmostafa> well let me see if just trashing it in clean lets it get rebuilt properly -- seems more the right thing to do, yes?
[06:40] <persia> Try using the upstream one first, and make sure it gets trashed in the build.
[06:40] <persia> That's a smaller diff.
[06:43] <kamalmostafa> Oh wait... I think I tried something like this once before (actually maybe it *was* exactly this) and discovered that bzr won't let me commit changes to a binary file -- so I think its not possible to replace fr.gmo.   Yes?  No?
[06:43] <persia> Right.
[06:44] <persia> So, you just don't change it.
[06:44] <kamalmostafa> back to the "trash it in clean" idea then?
[06:44] <persia> There's lots of ways to do that, but from where you are now the easiest is probably to unpack the upstream tarball in another tree, and copy the upstream file into your working branch.
[06:45] <persia> Ideally it won't come to delete-on-clean: let's keep that in reserve.
[06:45] <kamalmostafa> you lost me... I have the "new" fr.gmo but I won't be able to bzr commit it.
[06:46] <persia> Or at least, I'd do it that way: my preference is to strive for the smallest amount of packaging possible for a given source.
[06:51] <duanedesign> hmm running the PackagingGuide/Recipes/PackageUpdate i am getting an error
[06:51] <persia> OK.  What error, for what operation?
[06:51] <duanedesign> is there a chance that the...oh hi persia
[06:52] <persia> Yes :)
[06:52] <duanedesign> debuild -S -sa
[06:52] <kamalmostafa> persia: hmmm.  well, actually, it looks like bzr will let me commit such a change after all.  I've got a new libtifiles package built here, against the proper .orig -- I'll upload a new branch and we can continue with that.
[06:52] <duanedesign> dpkg-source: warning: source directory 'brasero-0.6.1' is not <sourcepackage>-<upstreamversion> 'brasero-0.5.2'
[06:52] <duanedesign> thats where it starts^^
[06:53] <persia> duanedesign: I'm a bit confused.  My apt-cache shows brasero 2.29.90-0ubuntu1
[06:53] <persia> Are you working on feisty?
[06:54] <duanedesign> i was wondering if the problem might be the how-to might need to be updated
[06:54] <persia> Oh, you're just following the commands in the guide directly?
[06:55] <duanedesign> persia: yeah i am getting the sources from daniels people.ubuntu,com sftp site
[06:55] <persia> Oh.  I think that's a waste of your time, but yeah, it probably needs an update.
[06:55] <persia> I'm not the right person to do it though, because I'd drop all the references to any specific package.
[06:56] <duanedesign> persia: ok. I think i understand the process though :)
[06:56] <persia> But the issue you have is probably a lack of an orig.tar.gz file that you need, and some native packages.
[06:56] <persia> Or else the guide is just completely wrong.
[06:57] <persia> Personally, I just apply the old diff to the new upstream manually, and tweak.
[06:58] <persia> And the VCS way to do it is with --import-upstream
[06:58] <persia> Err, --merge-upstream
[06:58] <duanedesign> ok. thank you
[06:59] <lifeless> persia: bzr merge-stream (no --)
[06:59] <persia> But it doesn't matter how you do it, really, as long as you retain the core packaging, review any patches to the source and rebase them, and use the new upstream.
[06:59] <persia> lifeless: `bzr merge-upstream` ?
[07:00] <lifeless> yes
[07:00] <lifeless> bzr merge-upstream --version=xxx tarball path-to-upstream-release-branch-if-it-exists
[07:00] <persia> `bzr merge-stream` would be really cool though, with some autodetection to determine if it was upstream or downstream, and appropriate handling of the patches, etc.
[07:01] <lifeless> indeed
[07:01] <persia> (although I suspect this would require that the package be Format: 3.0(bzr))
[07:01] <lifeless> If you want to practice your python I can offer places to hook in.
[07:01] <lifeless> persia: hell no:)
[07:02] <RAOF> lifeless: It is immensely cool that bzr can store arbitrary stuff as revision properties.  The use of pristine-tar by bzr builddeb is wonderful.
[07:02] <persia> lifeless: So, how does one know what to do with downstream stuff being merged?  Analyse the source package to determine a patch system, and make a best-effort application?
[07:02] <lifeless> RAOF: :>
[07:03] <lifeless> persia: I'm not sure I'm parsing that right. Can you elaborate
[07:04] <persia> lifeless: So, if the package is Format: 3.0(bzr), we can easily handle merging of downstream patches with `bzr merge-stream` in a way that doesn't interfere with whatever we have defined as "upstream" within bzr (presumably something that lets us use pristine-tar).
[07:04] <persia> If it's not Format: 3.0 (bzr), then we need some way to handle downstream patches in a safe manner, and I think that gets complex.
[07:05] <persia> Because there are N patch standards, plus auto-patching with Format: 3.0 ({quilt,git,foo}
[07:07] <lifeless> persia: I am missing something
[07:07] <lifeless> how is a 'downstream' patch different to a patch
[07:07] <wgrant> I don't particularly like the idea of 3.0 (bzr).
[07:07] <lifeless> and why would merging a downstream patch be difficult
[07:07] <persia> lifeless: The only way in which it differs is that we're extracting it from some artifact with `bzr merge-stream`
[07:08] <persia> And it's trivial to merge in bzr, but it may be complex to merge in a source package.
[07:09] <persia> wgrant: Any particular reason?  How is it less good than arbitrary Format: 3.0{!native} ?
[07:09] <kamalmostafa> persia: FYI, new libtifiles branch is attached to bug 507741.  1. corrected the .orig.tar.gz discrepancy 2. refreshed fr.gmo.
[07:09]  * persia hopes this branch actually downloads, unlike the libticalcs one
[07:09] <kamalmostafa> remember that you can just grab that diff from the "green text" there if you prefer that.
[07:10] <persia> Right, but the "diff" is going to require binary patching to encode the differences in fr.gmo, which I'm not going to be able to apply with patch.
[07:11] <wgrant> persia: At the point where we have everything in bzr, I don't think source packages should exist.
[07:11] <kamalmostafa> ah yes -- fr.gmo is out to get us one way or another.  well I hope the bzr branch downloads too.
[07:11] <persia> kamalmostafa: The bzr branch downloaded, but I still get the fr.gmo error.
[07:12] <persia> kamalmostafa: Could you attach your working diff.gz to the bug?
[07:13] <kamalmostafa> persia: done
[07:13] <persia> wgrant: Well, that strongly depends on a definition of "we" :)  Making source packages not exist requires lots of coordination over lots and lots of people.
[07:14] <lifeless> persia: I still don't get whats hard or likely to fail.
[07:14] <lifeless> persia: you seem to be saying 'merge-upstream has trouble'
[07:14] <lifeless> persia: I think I need you to step me through it, line by line if you like.
[07:15] <wgrant> persia: Indeed. But we will within a few months be at a point where one needn't touch a source package any more.
[07:15] <persia> lifeless: As I understand it, merge-upstream reads from some artifact, performs bzr merge between the current branch and changes from the artifact, and adds revision properties that would indicate that the merged branch included the upstream artifact.  Is this correct?
[07:15] <persia> wgrant: Unless one works in Debian as well :)
[07:16] <lifeless> by artifact, do you mean tarball ?
[07:16] <persia> Could be a tarball, sure.
[07:17] <persia> I'd hope it could work for a plaintext script, zip file, etc. as well.
[07:17] <lifeless> no
[07:17] <persia> (not that it does, but that the fact that it may not would be considered an absent feature)
[07:17] <lifeless> it's /intent/ is 'uupdate'
[07:17] <lifeless> its composed of smaller steps
[07:17] <persia> Right.
[07:17] <lifeless> but something that uupdate cannot conceptually do, neither can merge-upstream
[07:18] <persia> I don't see any conceptual reason why uupdate couldn't handle a zip file or plaintext script if that was how the upstream data was delivered, and appropriate support was in dpkg.
[07:18] <lifeless> so zip (maybe if we repack, or if debs could use zips)
[07:18] <persia> But that's a side issue.  Lets talk about tarballs :)
[07:18] <lifeless> I don't know what you mean by 'plaintext script'
[07:19] <lifeless> if you mean self extracting uuencoded shell script... there is a hell.
[07:19] <persia> Some python/perl/shell script
[07:19] <lifeless> mmm, totally different proposition
[07:19] <persia> But it doesn't matter.  let's talk about the subset of artifacts that are tarballs.
[07:19] <lifeless> ok
[07:20] <persia> Well, the difference between a file and a tarball contianing only that file is only some headers :)
[07:20] <lifeless> so it imports the tarball onto a 'tarball branch' which is a magic branch carried around as tags by bzr-builddeb
[07:20] <persia> Right.
[07:20] <lifeless> it then does a normal merge[optionally an octopus merge] from that branch into your working tree
[07:21] <lifeless> the import step is what adds the rev props
[07:21] <duanedesign> persia: what is 'rebase' the patches?
[07:21] <persia> OK.  So the order of steps was wrong, and the way it really works makes more sense, but the result is similar, right?
[07:21] <lifeless> note that 'changes' isn't really a concept in bzr; its not a patch based system.
[07:22] <persia> duanedesign: You might have a patch that applied to some previous file and that file was changed by upstream, so the patch might need to be adjusted to correctly apply to the changed upstream file.
[07:22] <lifeless> persia: yes, though I worry about what freight you have on 'changes from the artifact'
[07:22] <duanedesign> persia: ahhh, gotcha. Thanks again :)
[07:23] <persia> lifeless: BY "changes from the artifact", I only mean that some set of files may differ between revisions of the tarball, and that the set of these changes is brought into the branch.
[07:23] <lifeless> hmm, my firefox now has a tlh plugin
[07:23] <persia> lifeless: So, if I release 1.0, and then I fix a bug, and release 1.1, that bugfix gets into the branch after bzr merge-upstream.
[07:24] <lifeless> just need pitti/scott to do enough translating and we can surf in klingon ;)
[07:24] <lifeless> persia: ok, sure.
[07:24] <persia> Needs more support from webpage authors as well, and a good font :)
[07:24] <lifeless> persia: needs unicode code points in fact
[07:24] <persia> So, with bzr merge-stream, the source artifact may not be upstream.
[07:24] <lifeless> kindof a pre-req for the font
[07:25] <lifeless> persia: uhm, what do you mean by that
[07:25] <persia> So we don't want to interfere with the magic "tarball branch", and we won't end up with a generated source package that would be based off the artifact from which we're merging.
[07:26] <persia> lifeless: Consider the case that Mint has a source package including their differences somehow.  That might be sample downstream target.
[07:26] <persia> Or 64Studio, or any other downstream.
[07:26] <lifeless> why would you run merge-upstream then ?
[07:26] <persia> You wouldn't.
[07:26] <persia> I thought we were talking about how some new nifty `bzr merge-stream` might potentially work.
[07:27] <lifeless> ok. What is the problem you want to solve w.r.t. mint or 64studio
[07:27] <persia> merge-upstream seems to work great, as it.
[07:27] <persia> s/it/is/
[07:27] <lifeless> persia: I'd like merge-upstream to use watch files to find upstream tarballs.
[07:27] <kamalmostafa> persia: was the diff.gz that I posted what you were looking for there?  I don't know what to make of the fr.gmo situation -- but its getting close to my bedtime.  :-)
[07:27] <lifeless> which reminds me, I haven't filed that bug
[07:27] <persia> kamalmostafa: It looks perfect, but I've been distracted, and haven't tested it yet :)  Pulling now.
[07:28] <persia> lifeless: Rather than just using a watch file, it ought try first with debian/rules get-orig-source
[07:29] <lifeless> persia: I thought watch files trumped, because some gos rules do an upstream export
[07:30] <persia> lifeless: No, g-o-s trumps, because one can have a useful watch file for a source that needs to be cleaned to generate a dfsg tarball.
[07:31] <lifeless> ah
[07:36] <persia> kamalmostafa: Here's the sequence of commands I've used to construct a candidate package:  http://paste.ubuntu.com/380821/  Please confirm this matches the package you wish created.
[07:37] <persia> kamalmostafa: Also, is there a reason this shouldn't be 1.1.2-0ubuntu1 ?
[07:38] <persia> Oh, there is.  Ignore that last question :)
[07:43] <kamalmostafa> persia: okay, yes, that looks good to me.
[07:46] <kamalmostafa> persia: yes, it diff's clean to my working tree (+/- config.{sub,guess})
[07:46] <persia> kamalmostafa: OK.  Now what you've produced seems *very* close to libtifiles 1.1.1-1, but much less close to libtifiles-1.1.2-0ubuntu1.  Are you sure you aren't patching away some of the upstream changes from 1.1.1 to 1.1.2?
[07:47] <persia> kamalmostafa: Compare `lsdiff -z libtifiles_1.1.1-1.diff.gz` and `lsdiff -z libtifiles_1.1.2-0ubuntu2.diff.gz` : Is all that intentional?
[07:48] <kamalmostafa> persia: I was sure of it 5 weeks ago!  ;-)   As I remember it, there really was only *one* actual source difference:  a char array[63] that changed to [64].   All the rest was due to automake 1.10 vs 1.10.1.
[07:48] <persia> `lsdiff -z libtifiles2_1.1.2-0ubuntu1.diff.gz` is also small.
[07:52] <persia> kamalmostafa: I'm just a bit confused, because the files changed in your diff.gz almost precisely match the set of files I see if I unpack the old and new tarballs, and run `diff -urN libtifiles2-1.1.1 libtifiles2-1.1.2`, except your patch changes all the upstream changes in 1.1.2 back to the 1.1.1 state.  Is this intended?
[07:54] <kamalmostafa> Are all the "reverted" changes generated files from the automake 1.10.1 reconfiguration in libtifiles 1.1.2 perhaps?   All except for src/comments.c (the one real source change)?
[07:55] <persia> Most of it looks like that.  It appears that substantive changes between 1.1.1 and 1.1.2 are Changelog, comments.c, README, fr.po, and tifiles.h
[07:56] <kamalmostafa> Maybe I actually just cherry-picked the comments.c change (that was that one actual source change [63] to [64]) and fr.po (?) and applied that to 1.1.1 in order to minimize the diff from Debian.   tifiles.h diff was just an rcs comment date iirc.
[07:57] <persia> OK.  If that's what you want to do, you want to base off the 1.1.1 tarball.  The issue there is that we already have a newer binary, so that will fail-to-upload.
[07:58] <persia> I think you want to base off 1.1.2 because we already have that in Ubuntu, and try to get Debian updated.
[08:00] <kamalmostafa> hmmm.  i thought that setting the version number of the new package (my 1.1.2-0ubuntu2) higher than any Debian or Ubuntu version was sufficient (ScottK also thought this was right).   not right?
[08:01] <persia> It is sufficient, but in that case, you'll want to base off the 1.1.2 tarball.  I guess I just don't really like the idea of shipping a 1.1.2 tarball and patching it mostly back to 1.1.1 in terms of how this may be perceived by the authors of the software.
[08:02] <persia> "We go to the trouble of making a new release, and Ubuntu undoes all our work!  Why!"
[08:03] <persia> so, I'd want there to be a really good reason for this decision.
[08:04] <kamalmostafa> the only work we're "undoing" is automake...  we've carefully retrofitted the one upstream source change.  but you're right that there's no reason why we couldn't base off of 1.1.2 except that we'd then have a big diff from Debian.  If that's not a problem, then lets do that.
[08:04] <kamalmostafa> (lets base off of 1.1.2)
[08:05] <kamalmostafa> I agree that there's no "good reason" for such a decision
[08:06] <persia> kamalmostafa: OK.  So, if I'm understanding the workflow properly, you'll want to do something like the following:
[08:06] <persia> 1) branch libtifiles, 2) copy the libtifiles2 tarball to the right name, 3) bzr merge-upstream the copied tarball, 4) apply your changes, 5) create a source, etc.
[08:08] <kamalmostafa> I haven't used "bzr merge-upstream" before, but will investigate it.  I'll let you know if I find myself diverging from that workflow.
[08:09] <persia> kamalmostafa: I'm very much not an expert on that workflow, so you may want to ask others for better guidance.  I'd just untar the new tarball, apply the packaging from Debian, apply the Ubuntu changes I wanted to preserve, and create a source.
[08:09] <persia> But this is probably more complicated in the details :)
[08:10] <kamalmostafa> persia: okay, I think that I have a *much* better understanding of the whole situation than I did 3 hours ago (and certainly much much better than when I first did this work) -- so I think I can probably have another go at it at this point.  But it'll have to wait until tomorrow night, as I'll be busy tomorrow day.
[08:13] <persia> kamalmostafa: OK.  I'll clear out my local mess.  Just resubscribe the sponsors when you have something ready.  I'll recommend providing some instruction as to how to get the tarball for the sponsor: no matter what workflow they use, the trick of grabbing the libtifiles2 source tarball is going to be non-obvious.
[08:14] <persia> Oh, and you probably want to detach any branches that don't work, and delete any attachments that don't work :)
[08:14] <persia> (and cancel any pending merge proposals, etc.)
[08:15] <kamalmostafa> persia: very good.  thanks, as always, for all your help.  I'll go clean up the LP branches before heading off to bed.  :-)
[08:15] <persia> Have a good night.
[08:22] <persia> bdmurray: Just out of curiosity, why did "Ubuntu Reviewers Team" get unsubscribed from bug #524043?
[08:23]  * persia is currently fixing it, but it seems to clearly be a patch in need of review, rather than a candidate in need of sponsoring
[08:30] <persia> bdmurray: The same is true for bug #393212
[08:31] <randomaction> actually, why are sponsors subscribed to bugs with patches, as opposed to debdiffs?
[08:31]  * persia ignores that one for now, it not actually fixing the bug.
[08:31] <persia> randomaction: I claim they shouldn't be.
[08:31] <persia> My assertion is that a patch needs attention by developers doing code review, and sponsoring is only for developers needing to upload stuff to which they have not (yet) been granted upload rights.
[08:32] <randomaction> I would expect the patches review team to convert patches into debdiffs prior to subscribing sponsors.
[08:32] <persia> And that patch review ought be about trying to get the best working patch into a package, whereas sponsoring ought be about making sure the sponsorees understand Ubuntu processes and have good practices at integrating code changes.
[08:33] <persia> Indeed, or, as is the case here, I'd expect a developer with upload rights to just upload if they found a patch they thought was suitable for upload.
[08:34] <persia> Someone who can upload finding a patch and confirming it works and then subscribing another team to upload it without making a candidate is just shifting work around whlst not accomplishing anything.
[08:34] <persia> Seems not much harder to run dput than to fiddle subscriptions if a patch has been tested.
[08:36] <persia> OK.  sponsors queue now down to one bug I don't understand well enough to be able to confirm the solution, and one that isn't sponsorable and annoys me.
[08:37] <persia> If anyone has familiarity with git-buildpackage, bug #525116 would benefit from inspection
[08:41] <randomaction> I think this needs attention from the release team
[08:44] <persia> Oh, those are all new features, aren't they.
[08:45] <randomaction> I'd definitely call dpkgv3 support a feature
[08:47] <randomaction> by the way, is unsubscribing u-u-s ok while the package is waiting for FFe?
[08:48] <persia> I think so, as long as you leave a comment in the bug inviting it to be resubscribed to the sponsorship queue when the FFe has been approved.
[08:48] <persia> People get really annoyed when they get an approval, and it doesn't get uploaded, but most of the release team won't both approve and upload in the spirit of peer-review.
[08:49] <randomaction> ok, I'll take care of this bug (looks like ubuntu-sru was subscribed by mistake)
[08:49] <persia> Cool, which just leaves the messy cowsay bug, which I'm sorely tempted to just assign to bdmurray (except this would violate the assignment guidelines)
[08:51] <crimsun> it totally doesn't make sense to assign yet another team just because there isn't a debdiff there
[08:51] <crimsun> you've upload privileges because you know how to do it
[08:52] <persia> Indeed.
[08:52] <persia> But the patch author doesn't deserve to see us complaining to each other about workflow in the bug log.
[08:54] <persia> And the patch doesn't actually completely fix the issue, either, which makes just uploading it less interesting.
[08:54] <persia> (or at least that is what is claimed by the developer who didn't upload)
[09:02] <randomaction> Looks like most or all of "- branch" entries in the sponsoring list are for universe as well.
[09:03] <persia> Which list?  I think I'm looking at something different than you.
[09:03] <randomaction> http://qa.ubuntu.com/reports/sponsoring/
[09:06] <persia> I believe '-' indicates it's not in any packageset, although I could be mistaken.  It ought be worth updating the code to add "MOTU" when there isn't any other packageset.
[09:06] <persia> This helps define our new role better, and also highlights any packages where either the packageset detection has failed, or we ought have upload access.
[09:37] <persia> Anyone know anything about KDE .la files?  I'm not sure whether the patch in bug #290304 should be uploaded.
[09:46] <persia> Not that anyone seems lively, but I'm getting "error: 'NULL' undeclared here (not in a function)" for http://paste.ubuntu.com/380869/ and have no idea how to address that.  Hints welcome :)
[09:47] <lifeless> its not a built in in C++ IIRC
[09:47] <lifeless> need to include the right header
[09:47] <lifeless> or maybe thats C. either way ;)
[09:48] <persia> That's supposed to be C.
[09:48] <persia> So just including headers should do it?
[09:48] <jariq> jj
[09:49] <persia> (this explains why it built in feisty, which was the last time this package was uploaded)
[09:49] <lifeless> wag
[09:49] <lifeless> but yes
[09:49] <persia> No, it makes sense.  The toolchain used to automatically include nested headers back then.
[09:51] <randomaction> for C, stdlib.h
[09:55] <jariq> Is there something like PPA for debian?
[09:58] <persia> jariq: Lots of them, actually, but no "official" one.
[10:02] <jariq> persia: Can you please give me link to any? I am having trouble to create pbuilder environment for sid so I would like to test my package somewhere else..
[10:07] <persia> jariq: Sorry: I don't know of any that have open joining policies offhand.
[10:15] <Rirto6> hi
[10:15] <Rirto6> Could you recommend a good example of what a MakeFile should look like?
[10:18] <jariq> Rirto6: it is project dependand but it is a good practice to put clean distclean install a uninstall targets into makefile
[10:18] <persia> Rirto6: It really depends on what you're trying to accomplish.  My current favorite is: "#! /usr/bin/make -f\n%:\n\tdh $@\n"
[10:18] <Rirto6> hmm
[10:19] <Rirto6> I'm just looking for a simple makefile which copies a file over to a specific location
[10:19] <persia> OK.  How are you planning to use this makefile?  If you're packaging something, you probably don't need it.
[10:19] <Rirto6> It's Java, so no compilation is necessary. However it seems I need a MakeFile to create dpkg
[10:20] <Rirto6> .deb
[10:20] <persia> No you don't.
[10:20] <Rirto6> persia: Okay!
[10:20] <Rirto6> That saved me some time
[10:20] <Rirto6> Now to find a good rules file for Java apps
[10:20] <Rirto6> ...
[10:20] <persia> /usr/share/doc/debhelper/examples/rules.tiny
[10:20] <Rirto6> Thanks
[10:21]  * Rirto6 goes to get red liquorice
[10:22] <persia> A few idle notes: 1) #ubuntu-java may be as good a place for the discussion, 2) We do recompile all the Java applications in Ubuntu, and 3) If you have Java source, you probably want to be using ant rather than make anyway.
[10:42]  * Rirto6 is back with red liquorice, juice, toothbrush & toothpaste
[10:42] <Rirto6> persia: Thanks, wasn't aware of that channel
[10:52] <dan4dm> hi - lintian stuff, I'm getting "debian-watch-file-in-native-package" but the package is not 'native' - the .orig.tar.gz has no watch file in it - any suggestions?
[10:53] <azeem_> dan4dm: pastebin the content of your .changes
[10:54] <dan4dm> http://pastebin.ca/1804500
[10:54] <azeem_>  ccf91f882822ff25da008988784247c4c4ef178c 8579903 supercollider_3.3.1-0ubuntu1~karmic1.tar.gz
[10:54] <azeem_> no .orig.tar.gz
[10:55] <persia> dan4dm: You've seen artfwo's packages on REVU?
[10:55] <dan4dm> persia: recent ones? i saw them a while back, just updating the packaging to the latest upstream
[10:56] <persia> dan4dm: OK.  You might want to collaborate there: I know a bunch of packaging there is in fairly good shape (and recently commented on what I think are the remaining bits to hit)
[10:56] <persia> http://revu.ubuntuwire.com/p/supercollider
[10:56] <dan4dm> azeem_: ah thanks. i have an .orig.tar.gz but its name doesn't quite match
[10:56] <persia> 3.3.1 is better than 3.3.0, but :)
[10:59] <dan4dm> persia: great, thanks for the comments, will contact artfwo
[11:01] <persia> dan4dm: It's looking closer than I've seen it in a very long time :)  I hope to see it back in the repositories soon.
[11:02] <dan4dm> persia: yes! the recent version supports amd64 properly (no 32libs) too
[11:03] <persia> dan4dm: Really?  The data structure was changed?
[11:03]  * persia considers getting up to dance about
[11:04] <dan4dm> persia: yes. someone (not me) did a nice job of abstracting the sclang access and providing 32 and 64 -bit implementations under the hood
[11:04] <persia> That's very exciting!
[11:05]  * sebner looks what supercollider is and why persia is so excited about it :)
[11:06] <dan4dm> BTW for that minus-sign issue, is it easy to grep for the offending characters? I see some \- in front of args maybe it's fixed
[11:07] <persia> dan4dm: I usually let lintian check for me, but if there are some \- and \(hy, it may be fixed.
[11:07] <persia> Some of that comes from code generators, and more and more of those are getting fixed.
[11:13] <randomaction> dan4dm: lintian gives file name and line number
[11:15] <dan4dm> artfwo: fancy seeing you here!
[11:15]  * dan4dm was just chatting about supercollider deb
[11:15] <artfwo> hi! :)
[11:16] <artfwo> xchat freaks out when you're performing a /me action
[11:16] <Rirto6> No it doesn't!
[11:16] <Rirto6> Upgrade to latest version :P
[11:16]  * dan4dm freaks folks out
[11:17] <artfwo> I'm using the one available in lucid repositories
[11:17] <artfwo> I hope it's the latest
[11:18] <artfwo> yet I can't see what dan4dm is doing when he uses /me :)
[11:18]  * dan4dm insults artfwo's family
[11:19] <persia> !ohmy
[11:19] <artfwo> This time it showed: * dan4dm insults artfwo's family
[11:19] <persia> It's always when one thinks one is safe that one gets caught :)
[11:20] <persia> Anyway, about supercollider.
[11:20] <persia> So, 3.3.0 *finally* got to the top of the REVU queue, and 3.3.1 is out, and both of you have been working on it in different ways.
[11:20] <persia> So, where do we go from here?
[11:21] <artfwo> aren't we past the feature freeze already?
[11:21] <Rirto6> 3.3.2
[11:21] <persia> artfwo: We are, but squeeze hasn't frozen, so it can go there (since it obviously has a dedicated maintainer, even out-of-archive)
[11:22] <persia> And then we'll sync, and no more REVU madness :)
[11:22] <dan4dm> ok well the situation is 3.3.1 is out, the sc devs are thinking about putting out 3.3.2 (which is what will have the proper 64-bit support),  ...
[11:22] <artfwo> that's good
[11:23] <artfwo> (dan4dm, I haven't followed the mailing lists for the last month)
[11:23] <dan4dm> ... and artfwo and me are both working on the deb stuff but not exactly out-of-sync since we both work from the deb stuff stored upstream
[11:23] <artfwo> yep
[11:24] <artfwo> there are still a couple of unresolved issues
[11:24] <artfwo> most notably lib-without-soname
[11:24] <artfwo> brb
[11:25] <persia> There's an easy way around that one: declare it a private lib, and stick it in a private namespace.
[11:25] <persia> MInd you, nothing else will be able to compile against it, but ...
[11:25] <persia> (of course, having a SONAME would be better)
[11:35] <dan4dm> ok for the REVU process, is it best to wait until 3.3.2 is out, or upload an improved packaging of 3.3.1?
[11:35] <dan4dm> no wait
[11:36] <dan4dm> is it best to wait until 3.3.2 is out, or upload an improved package based on a dev snapshot?
[11:42] <persia> dan4dm: Unless something is unexpected, the packaging and upstream should be separable to some degree, so may as well upload 3.3.1 to REVU (or even 3.3.0) with improved packaging, and get that right, independently of the upstream work.
[11:43] <persia> Then, when 3.3.2 comes out, revalidate it against the then-perfect packaging, and get it into a repo.
[11:43] <persia> (either squeeze or lucid+1, depending on the timeframe)
[11:43] <dan4dm> persia: ok though the packaging code i'm tweaking right now isn't quite applicable to 3.3.1 because of the new 64bittability
[11:44] <dan4dm> i'm aiming to put a supercollider dev snapshot on my ppa
[11:45] <persia> dan4dm: My memory was that it FTBFS on amd64 with the older ones: as long as you don't mind the build-failure, just go ahead.
[11:45] <persia> Once 3.3.2 is available, amd64 will magically build.
[11:45] <persia> The only folk not supported will be those that wanted to run 64-bit server and 32-bit client (or was it the other way about).
[11:58] <artfwo> persia, how do we declare a private lib?
[11:58] <dan4dm> artfwo: i think probably best to jsut set the soname
[11:58] <dan4dm> i'm working on that right now
[11:59] <artfwo> ah, then almost everything is set
[11:59] <artfwo> dan4dm, do you have the latest packaging tweaks in svn?
[11:59] <dan4dm> artfwo: no not yet, i've done some stuff in the past hour that i'll commit once it works ;)
[12:00] <artfwo> okay, I'll update my local copy then and try building it here
[12:00] <artfwo> persia, once we have resolved the issues you've mentioned in REVU, how do we push supercollider in squeeze?
[12:07] <persia> artfwo: I'd file an ITP, close it with a changelog entry, and send an RFS to the debian-multimedia team.
[12:08] <artfwo> doesn't it have to go through debian-mentors webiste?
[12:08] <artfwo> *website
[12:09] <persia> No, nothing does.
[12:09] <persia> That's just a convenient place to upload a package for review.
[12:09] <persia> Similar to REVU in many ways.
[12:09] <artfwo> but we have to host the package somewhere
[12:09] <persia> Right, so if you don't want to host it, mentors.debian.net will host it for you :)
[12:10] <artfwo> REVU is nice, because it has semi-automatic copyright checker etc., I just wonder is it okay to point the ITP to a REVU package
[12:12] <persia> Should be OK, as long as you set up the package for Debian (-1 rather than -0ubuntu1, real maintainer, etc.)
[12:12] <persia> But that "copyright checker" is just running licensecheck.  You can do that locally.
[13:10] <AnAnt> Hello, where does pbuilder-dist put the base.tgz, aptcache & result ?
[13:10] <AnAnt> for a distro X
[13:11] <dan4dm> AnAnt: oh it's somewhere like /var/lib/pbuilder/cache isn't it? (IIRC)
[13:11] <geser> AnAnt: ~/pbuilder
[13:11] <AnAnt> geser: ~/pbuilder/X ?
[13:11] <dan4dm> oh /var/cache/pbuilder i see on mine
[13:12] <AnAnt> geser: or does it put the base.tgz, result & aptcache in same dir for all distros ?
[13:12] <geser> dan4dm: depends if you use pbuilder or pbuilder-dist
[13:12] <dan4dm> geser: ok thanks i'll pipe down
[13:13] <geser> AnAnt: one moment, looking at the source
[13:14] <geser> yes, all should be below ~/pbuilder
[13:15] <AnAnt> hmmm, ok
[13:17] <AnAnt> ~/pbuilder/X_....
[13:19] <Laney> james_w or StevenK: Could you run these syncs: http://pastebin.com/d3d5046e7 ?
[13:20] <persia> Laney: You might find https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days a handy reference when finding someone to poke.
[13:21] <persia> Nobody is ArchiveAdmin on Sundays (although sometimes people do stuff out of turn)
[13:21] <Laney> persia: yes, that's why I was pinging
[13:21] <persia> heh.  I guess you might be lucky :)
[13:22] <persia> Although the rest of the listed archive-admins (excepting al-maisan) are all also in the channel :)
[13:23] <Laney> those are ones to have offered me help with the Haskell transition
[13:23] <persia> Ah.  It all makes sense now :)
[13:27] <james_w> Laney: the release team is happy with this?
[13:28] <Laney> james_w: I informed them, and there were no complaints ;-)
[13:29] <Laney> http://orangesquash.org.uk/~laney/graph.png this is the world atm
[13:29] <james_w> on it
[13:29] <james_w> whoah
[13:30] <Laney> oh, I missed haskell-hlist from the list
[13:31] <james_w> unstable?
[13:31] <Laney> yes please
[13:31] <Laney> did I get the syntax right?
[13:31] <Laney> it doesn't say my LP ID anywhere
[13:31] <james_w> I added that
[13:31] <AnAnt> Laney: they still don't use dh7 in haskell ?
[13:32] <Laney> no
[13:32] <AnAnt> ok
[13:32] <james_w> Laney: ldap-haskell is modified
[13:33] <Laney> oh, yes. Please override that
[13:35] <james_w> Laney: INCOMING!
[13:35] <Laney> hoorah!
[13:35]  * Laney high fives james_w 
[13:35] <Laney> the next round should be a bit bigger
[13:36] <Laney> there's also a removal in 524987 if you feel like it
[13:45]  * james_w goes strangely quiet
[13:48]  * Laney notices his LP mailbox bulging
[13:48]  * Laney runs
[14:03] <shadeslayer> Laney: theres a LP mailbox too?
[14:03] <shadeslayer> (i bet its really exclusive)
[14:05] <Laney> shadeslayer: no, not like that
[14:07] <shadeslayer> Laney: then? by LP i assume you mean Launchpad :)
[14:08] <Laney> of course
[14:12] <persia> shadeslayer: Massive volumes of mail flowing from an overabundance of bug subscriptions, package subscriptions, build subscriptions, etc. through a filter into some bucket.
[14:13] <shadeslayer> persia: oh i have that too :P
[14:14] <persia> Not exclusive at all :)
[14:14] <shadeslayer> like 5-6 ML's and one of them is the kubuntu bugs ml and the regular mail :D
[14:14] <persia> Oh, I was thining even without mailing lists.  Adding mailing lists makes it even more.
[14:14] <shadeslayer> :)
[14:34] <james_w> Laney: still around?
[14:34] <Laney> yeah
[14:34] <james_w> I'm looking at the mono-tools merge
[14:34] <james_w> -debian/tmp/usr/share/applications/mprof*
[14:34] <james_w> is that part of the xsp changes?
[14:34] <Laney> do you have a bug number?
[14:34] <Laney> I think that I did this some time ago
[14:34] <james_w> bug 516260
[14:36] <Laney> let's see
[14:37] <Laney> james_w: is that from a binary debdiff?
[14:38] <james_w> no
[14:38] <james_w> source
[14:38] <james_w> http://paste.ubuntu.com/380999/
[14:38]  * Laney just looked at the bzr diff
[14:39] <james_w> yeah, that's what I'm working from
[14:40] <Laney> oh
[14:40] <Laney> james_w: that's an upload which was done since my merge
[14:40] <james_w> ah
[14:41] <Laney> I dunno what it is
[14:41] <Laney> let's see
[14:41] <james_w>   * debian/mono-profiler.install: Don't install .desktop file for mprof-
[14:41] <james_w>     heap-viewer. The binary name is incorrect and it requires an input file.
[14:41] <james_w>     anyway and so must be run from the command line (closes LP: #406909).
[14:41]  * james_w edits the changelog
[14:42] <Laney> sounds reasonable
[14:42]  * Laney checks that debian has it
[15:30] <ari-tczew> \sh: ping
[15:59] <bdrung> \o/ the universe sponsor queue is now empty again \o/
[16:01] <lightnin> highvoltage: Hello
[16:03] <highvoltage> hi lightnin
[16:03] <highvoltage> bdrung: \o/!
[16:04] <lightnin> highvoltage: Hiya. Do you know if scratch made it in time? I haven't heard anything.
[16:04] <highvoltage> lightnin: it's not in the archive yet, might be because it's weekend, might be because we didn't make it in timme for FF
[16:05] <bdrung> highvoltage: the main sponsor queue is a mess. 122 items: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=ubuntu-main-sponsors&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.aff
[16:05] <bdrung> ects_me.used=&field.tag=&field.tags_combinator=ANY&field.has_no_package.used=
[16:05] <highvoltage> lightnin: the topix still doesn't show we're in FF so I'm hoping we'll see it in tomorrow
[16:05] <lightnin> highvoltage: Ah - thanks! :)
[16:05] <persia> bdrung: Go complain to the slackers in ubuntu-devel :)
[16:06] <highvoltage> bdrung: yes hopefully the archive re-org is going to make that better someday! :)
[16:06] <persia> lightnin: scratch is in the source NEW queue (https://launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text=scratch) It likely needs a FeatureFreeze exception to get it out.
[16:06] <persia> !ffe
[16:07] <persia> (UVF is no more: someone should update the factoid)
[16:08] <bdrung> highvoltage: i doubt that
[16:08] <lightnin> persia: interesting- on that page the component is listed as "universe", not "multiverse"
[16:09] <persia> lightnin: Everything is universe by default.  An actual component is assigned by the archive-admins on acceptance.
[16:10] <Laney> !learn ffe is Feature Freeze
[16:10] <Laney> erm, oops
[16:10] <Laney> !learn ffe is Feature Freeze. For an exception, see https://wiki.ubuntu.com/FreezeExceptionProcess
[16:10] <Laney> !learn ffe is Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
[16:11]  * Laney pretends that didn't happen
[16:12] <lightnin> persia: Ah, thanks.
[16:15] <lightnin> persia: btw - still planning on releasing that source tarball soon, and then submitting to Debian. :)  But Mako and I were hoping to slip by and get into Lucid so we reworked a bunch of stuff on Friday.
[16:23] <dan4dm> artfwo: supercollider deb tweaks now in svn. mostly i was fixing paths and lintian complaints, not done many of persia's items yet. build in my ppa https://launchpad.net/~danstowell/+archive/ppa/ builds ok, not tried running yet
[16:28] <artfwo> dan4dm, thanks, will check this asap
[16:36] <dan4dm> persia: re "supercollider-common-dev probably has overambitious dependencies" - would you say that since that package is just headers etc, all of "libc6-dev, libstdc++6-4.4-dev | libstdc++-dev, libsndfile1-dev" can be simply dropped? i see the logic i think
[16:42] <dan4dm> artfwo: you're the inventor of sced are you? i forget... if so, maybe i can leave the add-copyright-info-to-sced issue to you
[16:47] <dan4dm> what's the relationship between .menu files and .desktop files? should always have both?
[16:48] <dan4dm> my perception is that .desktop spec supercedes .menu in some sense, tho i may be wrong
[16:50] <sebner> iulian: thx for the ACK, up for another one? ;)
[16:52] <iulian> sebner: Sure.
[16:52] <iulian> Bug#?
[16:52] <iulian> Hey sistpoty.
[16:52] <sebner> iulian: https://bugs.edge.launchpad.net/ubuntu/+source/bleachbit/+bug/525376
[16:52] <sistpoty> hi iulian
[16:52] <sistpoty> huhu sebner
[16:52]  * sebner huhus sistpoty and makes him his FFe ACK slave ;D
[16:53] <sistpoty> heh
[16:55] <sistpoty> cody-somerville, jdong, cjwatson, slangasek: SRU bug #463019
[16:55] <geser> dan4dm: you can probably drop libc6-dev and those libstdc++*-dev (as those are part of build-essential), but need to keep libsndfile1-dev if a .h file includes a .h file from it or libsndfile is mentioned in .la or .pc files
[16:55] <sebner> sistpoty: pfff, you are naive ... it's sunday :)
[16:55] <sebner> huhu geser :)
[16:56] <geser> Hi sebner
[16:56] <geser> dan4dm: .menu is for the Debian menu while .desktop is for the Freedesktop menu which is used by Ubuntu
[16:57] <dan4dm> geser: that makes sense, thanks. so would i add build-essential as a dep? i know in many cases we can assume it, but not always surely?
[16:58] <geser> dan4dm: no, it's expected that someone who wants to build something has build-essential (or its dependencies) installed
[16:58] <dan4dm> geser: k thanks
[17:00] <geser> dan4dm: "Build-dependencies on "build-essential" binary packages can be omitted." http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps
[17:01] <geser> and also http://www.debian.org/doc/debian-policy/ch-source.html#s-pkg-relations
[17:05] <dan4dm> geser: it's not a build-dependency though. but if that's the way it's done then that's fine
[17:07] <geser> dan4dm: right, but the most common use case for a -dev package is to be used as a build-dependency for other packages
[17:07] <dan4dm> geser: k thanks
[17:11] <iulian> sebner: Do we really want that version in Lucid?  There are only two changes that are for us, the other changes are specific to Windows.
[17:12] <fabounet> Hi BlackZ, did you have time to upload Cairo-Dock ?
[17:14] <iulian> DktrKranz: ^ Do you think it's worth getting bleachbit 0.7.3-1 into Lucid?
[17:14] <sebner> iulian: FF is pretty fresh and I like the TB support so I don't really see a reason denying
[17:14] <sebner> DktrKranz: yes, tell us .. what do you think! ;)
[17:25] <Laney> james_w: did you forget to upload mono-tools/
[17:26] <jdong> sistpoty: ACKed
[17:26] <sistpoty> jdong: thanks!
[17:27] <jdong> sure thing!
[17:42] <kamalmostafa> persia: fyi, a new cut of libtifiles is ready for review at bug 507741 (attached branch).  I did enjoy bzr merge-upstream" btw -- worked like a charm!  shall I assign to you, or to nobody and u-u-s?
[18:09] <DktrKranz> iulian: changes are limited to thunderbird cleaner, which is one of the widest app used, so I think it's fine having it in.
[18:17] <james_w> Laney: network failure
[18:20] <Laney> alright
[18:24] <james_w> done now
[18:24] <james_w> kamalmostafa: hey
[18:24] <james_w> kamalmostafa: that merge proposal you just made, did you want two reviews done, or just one?
[18:24] <kamalmostafa> james_w: hiya
[18:25] <kamalmostafa> um... persia and I worked on it extensively last night, so I would be happy if he took at look at it in particular (but you're most welcome to look at it also)
[18:26] <james_w> kamalmostafa: I think there may be a bug lurking here, so I'm interested in your intent
[18:27] <james_w> you clearly wanted to request a review from persia, but did you want a second review, or did you just do it the way that seemed obvious/seemed to be the only option
[18:28] <kamalmostafa> james_w: I just did what seemed obvious -- I clicked "Propose for Merge", then clicked "Add a reviewer" in order to specially 'notify' persia that I would like him to look at it.
[18:29] <james_w> kamalmostafa: were you aware that you could have requested the review from persia as you filed the request, hence only requesting a single review?
[18:29] <quadrispro> hello folks
[18:31] <kamalmostafa> james_w: no, I wasn't aware of that at all.  tell you what -- I'll start doing another merge proposal (but not complete it) and see if how hard it is for me to find the "single review" thing you're talking about -- and I'll get back to you -- but I need to leave immediately, so it'll have to wait until later.  good?
[18:31] <james_w> kamalmostafa: I think I have enough for the bug report already, thanks for the help
[18:32] <kamalmostafa> james_w: very good.  see ya.
[18:53] <iulian> DktrKranz: Alrighty.  Thank you for the info.
[18:54] <sebner> iulian: ;)
[19:01] <iulian> sebner: Acked.
[19:05] <sebner> iulian: thx :)
[19:06] <hggdh> kklimonda: here
[19:06] <kklimonda> We'd like to get another opinion about what to do with anjal in lucid
[19:07] <kklimonda> currently we have an "ancient version" and the sync was requested to get 0.1 from debian experimental but 0.3.1 got synced instead which won't build with evo/eds 2.28.x
[19:08] <hggdh> and we will not have anything but evo 2.28 in Lucid
[19:08] <kklimonda> now we could either cancel this upload and update package to 0.1 or remove anjal from lucid completely
[19:08] <Laney> just upload the old version
[19:09] <kklimonda> Laney: and who's going to support it?
[19:09] <hggdh> Laney: what is the advantage of providing a version that is not supported upstgream anymore?
[19:09] <Laney> the advantage of providing something over nothing
[19:09] <hggdh> I would rather go for a PPA with anjal and required evo libraries
[19:10] <hggdh> and no support?
[19:10] <Laney> who says?
[19:11] <Laney> if that sync had been for the correct version, would we be removing it right now?
[19:11]  * Laney thinks not
[19:12] <hggdh> kklimonda: ah well. There you go. We will keep, then, anjal 0.1, and no support.
[19:12] <Laney> i'm just giving a point of view
[19:12] <Laney> you can do otherwise if you like
[19:13] <hggdh> Laney: we would rather have a consensus. We do not right now, so we keep with what sould otherwise be done
[19:13] <hggdh> s/sould/would/
[19:15] <kklimonda> Laney: I see two problems - if we keep 0.1 we may get emails from developer who's getting reports from people using an outdated version of his software. Or we'll get report from people who are using an outdated version of anjal and who are surprised that it's so outdated.
[19:16] <kklimonda> of course we may not get any complains at all
[19:17] <kklimonda> I don't see the reason for shipping software just for the sake of shipping it - we are not debian after all ;)
[19:18] <pochu> kklimonda: Debian actively removes software that is RC buggy
[19:19] <kklimonda> pochu: I know, I was just trying to make a joke. Probably shouldn't :)
[19:20] <pochu> kklimonda: oh, that's the bad thing of IRC, it's harder to get the sarcasm :)
[19:21] <kklimonda> exactly why I should stop doing that :)
[19:24] <pochu> why will Lucid ship evo 2.28 and not 2.30?
[19:24] <dupondje> 2.30 normally no ?
[19:25] <pochu> yeah 2.30 would be the normal thing, but they may have decided to ship 2.28 if 2.30 is too buggy or whatever
[19:25] <james_w> I believe 2.30 is too much of a rewrite
[19:26] <james_w> with evolution not known for it's stability across versions
[19:26] <pochu> yeah, they have ported it away from various deprecated libraries
[20:15] <kkszysiu> any people from Poland there?
[21:01] <dan4dm> hi - REVU question, i have made new debs for supercollider but the stuff on http://revu.ubuntuwire.com/p/supercollider was uploaded by someone else. do i have a way to add files to that, or do i make a separate upload? actually i'm new to REVU and don't see where i upload the packages at all
[21:03] <geser> dan4dm: what about contact the other uploader and talk about cooperation?
[21:05] <ari-tczew> I've got installed lucid. Can I build packages for other releases using pbuilder?
[21:05] <azeem_> yes
[21:06] <ari-tczew> do I need to do any changes?
[21:06] <dan4dm> geser: yes no problem collaborating with him, fine. just thought i could add updated code myself. is it best if one person remains as champion?
[21:17] <crimsun> ari-tczew: changes from what to what?
[21:18] <ari-tczew> crimsun: changes needed to able building for other releases like dapper, hardy, intrepid, jaunty, karmic (security updates and sru)
[21:28] <crimsun> ari-tczew: well, it depends what you're modifying, of course
[21:28] <crimsun> ari-tczew: (i.e., I don't know whether you're referring to pbuilderrc or the source packages)
[21:30] <ari-tczew> @ pbuilderrc
[21:30] <ari-tczew> crimsun: I'm only adding patches, nothing changed in debian/control or rules
[21:31] <crimsun> ari-tczew: presuming you're using something like pbuilder-dist, no, nothing to really change. It's worth noting that you probably will want to add $release-updates, however.
[21:33] <ari-tczew> thanks
[21:34] <randomaction> does OCaml transition have some special approval from the release team? I mean, does jocaml need a normal FFe (bug 522358)?
[21:35] <geser> dan4dm: your upload would override the previous one and it would be better if the previous uploader knows about it instead of starting an upload war or similar
[21:37] <geser> randomaction: don't know yet, I only asked about the timing of the OCaml transition and slangasek told me that we could start it and it shouldn't be no problem to get FFes if necessary
[21:43] <slangasek> geser, randomaction: if the change is only to get it built against the new ocaml, that's a bugfix and needs no exception; if there are other feature changes included in the Debian version you're asking to sync, those still need to go through the usual FFe process
[21:43] <randomaction> the latter is the case here, so I'll tell the guy about the FFe process
[21:47] <dan4dm> geser: ok that makes sense, thanks for that detail. have emailed artfwo about my packages
[21:53] <ari-tczew> \sh: ping
[22:37] <persia> dan4dm: There's no need to depend on anything in Priority: essential, nor any of the dependencies of build-essential for -dev packages.
[23:32] <zooko> Ugh. Trying to finish Tahoe-LAFS v1.6.1 today. Running out of time.
[23:55] <ripps> Gmpc in the gmpc-trunk ppa installs alot of image files these days, so I was thinking of adding a gmpc-data package to save building time. Can simply move everything in /usr/share/* to it?
[23:56] <persia> ripps: You need to exercise a bit of care: there's some stuff that policy mandates should be in the base package (e.g. /usr/share/doc/)
[23:57] <persia> ripps: But lintian should help you catch anything: try it that way first.
[23:57] <ripps> persia: Yeah, I thought that dh7 would automatically make sure things like that were installed in the proper package
[23:58] <persia> ripps: It will try, but it's always possible to confuse it :)
[23:59] <ripps> persia: things like .mo locale files are arch-independent, correct?
[23:59] <persia> I'm actually not sure.  I know they are compiled, but I don't know if the compilation differs between different architectures.