[00:24] please universe sponsors for review bug 524912 [00:24] Launchpad bug 524912 in nautilus-image-converter "Fake sync nautilus-image-converter 0.3.0-3 (universe) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/524912 [00:35] 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] sistpoty: fakesynces for main too wastes time? [00:38] pointless uploads always waste time [00:38] ari-tczew: *if* these don't bring in changes then yes [00:38] (and CPU power, bandwidth, ...) [00:39] great! all my time is wasted! love you! [00:39] not only the upload wastes time, everyone having the package installed will also need to download the new version for no benefit [00:39] 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] you should target your efforts where they will have more impact [00:41] I'm merge-n00b, so I'm useless in FeatureFreeze [00:42] hmmm recently someone told me that fakesyncs are welcome in FF [00:42] and merges without new upstream release [00:42] and today you tell me that this is wasting time! [00:42] rofl [00:43] you need to zoom out a bit [00:43] it depends on why the fakesync [00:43] and think about what the upload is supposed to achieve [00:43] 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] 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] love you again <3 [00:45] 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] here is the debian/trac tree --> http://pastebin.com/f40099b75 [00:45] here is the structure when i extract the package (the deb file) --> http://pastebin.com/f36b9a83a [00:46] i don't understand !:/ [00:46] paissad: why you want to get new snapshot? [00:46] is it fixes something? [00:47] ari-tczew, mostly in order to have the translations , but there are many new & interesting features too ^^ [00:47] paissad: no! there is FeatureFreeze! [00:47] get out here! [00:47] ari-tczew, o0 [00:47] ari-tczew: please calm down a bit [00:48] sistpoty: I write just only true [00:48] ari-tczew, you're mad ? [00:48] paissad: yes :D FeatureFreeze and generally policy drive me crazy [00:49] ari-tczew, then i think it's you who need to get out of here .... go see a psy mate ! [00:49] well .. does somebody have any idea about my problem [00:51] 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] 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] i've been* [00:52] paissad: how did you get to the new snapshot? [00:53] Laney, from svn [00:53] svn export? [00:53] svn export yes ! [00:53] did you tar up the svn export and then uupdate with it? [00:54] Laney, yeah, i have a orig.tar.gz file created after svn export [00:54] maybe the build system changed somewhat [00:54] it might be an idea to just go with it unpackaged in /srv or whatever [00:55] sistpoty: no we dont sync [00:55] crimsun and other from team: easy man, slacken your tie! [00:55] paissad: do you have a debian/trac.install or debian/install file? [00:55] sistpoty: ok thats a misleading wording [00:55] its just latest gnash [00:55] geser, no i don't have a debian/install or debian/trac.install [00:55] ari-tczew: we have xulrunner-1.9.2 in a PPA if you want to test build your package against it [00:57] geser, i did not created an install file because my debian/rule file handle it http://pastebin.com/f3a5c4835 [00:57] micahg: great! but I don't know... there's feature freeze and ... :/ [00:57] ari-tczew: which package is it? [00:59] 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] 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] asac: thanks for looking :) [01:00] geser, and then,what must i do ? [01:01] i saw that warning " debhelper version lower than 5 ****" but i did not understand ... that's what i said [01:01] cody-somerville: afaict that's still true... did his behavior increase at least? [01:01] either update the debhelper version (as lintian suggest anyway) or "install" to debian/tmp too [01:02] micahg: libjdic-java [01:02] 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] geser, debhelper 7.4.15 [01:06] paissad: you need to tell which debhelper compat version your package needs (see the value in debian/compat) [01:06] 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] well he was asked by the MC to stop participating, right? [01:07] cody-somerville: *sigh* [01:07] so really I doubt they have jurisdiction over the whole of LP... [01:07] sistpoty, It doesn't look like he actually confirmed if they were upstream bugs or not either. [01:08] 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] geser, thanks for all [01:09] micahg: can I use reason like 'transition for xulrunner -> 1.9.2' for FFe merge libjdic-java? [01:10] ari-tczew: make sure it builds first, then worry about FFe, but yes, that works [01:10] bugfixes don't need FFe [01:11] *looks at clock* [01:11] did I really just spend the last 11 minutes trying to make the emacs doctor say a sexual innuendo? [01:11] *goes back to being productive* [01:11] actually, I don't know if that's true for this cycle [01:11] !jdong [01:11] I think that factoid is gone :) [01:11] damn :P [01:12] :) [01:13] crimsun: I just made this if you want to do any uploads [01:13] http://orangesquash.org.uk/~laney/graph.png [01:14] (looks daunting when zoomed out) [01:15] ari-tczew: please subscribe myself and asac to the FFe bug [01:15] micahg: sure! but give me a time for test [01:15] oh wait...no FFe needed :) [01:15] ari-tczew: yeah, I actually test built it in the PPA it seems to build ok [01:16] Laney: damn, there's too much red and too few green in there :P [01:16] 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] sistpoty: yes indeed, this is the fun of a Haskell transition [01:17] luckily it should be completely solved by syncing [01:17] ari-tczew: FFe is needed is it's new features not bug fix per above [01:17] *if it's [01:19] Laney: do we need to sync in order, or will packages land in depwait nowadays? [01:20] (or just ftbfs, which just needs more manual intervention, but wouldn't restrict to sync out of order) [01:20] at least for this first round we need to sync in order [01:21] Laney: ok, thanks [01:22] debian has the edge here because they can issue nmu and dw commands to wanna-build easily [01:25] actually you probably could just sync everything straight away [01:25] sistpoty: could you destroy my work too here? bug 512430 ; bug 524955 ; bug 524957 [01:25] Launchpad bug 512430 in geronimo-jpa-3.0-spec "Fake sync geronimo packages (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/512430 [01:25] Launchpad bug 524955 in polkit-qt "Fake sync polkit-qt 0.9.3-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/524955 [01:25] Launchpad bug 524957 in polkit-qt-1 "Fake sync polkit-qt-1 0.95.1-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/524957 [01:25] if soyuz had bd-uninstallable then it would be nicer [01:28] Laney: oh, so b-d's won't be installable if we sync out of order? [01:28] that's right, which is an FTBFS in soyuz [01:29] Laney: that's at least cool, because we then can click on retry and sync out of order :) [01:29] well I'm not sure that this gains anything [01:30] as james_w has said that I can bother him with lists of stuff to sync ;) [01:30] heh [01:31] last time we did this for (I think) ppc, as the world was broken there for a number of weeks [01:31] we just threw all of the FTBFS against the wall multiple times until it all went green [01:31] bit of a waste of buildd time though [01:34] how can I add PPA into pbuilder list? [01:34] well, only ia64 and sparc are busy, so ... :) [01:34] heh [01:34] ari-tczew: pbuilder login --save-after-login [01:34] ari-tczew: then modify /etc/apt/sources.list and add the ppa [01:35] i'll start syncing stuff tomorrow after ghc6 is built in more places [01:35] for now, nn [01:36] sistpoty: heh, but how can I edit file? nano doesn't work [01:36] 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] impossible! [01:36] ari-tczew: pbuilder should tell you a directory where the build chroot is extracted (right at the beginning) [01:37] ari-tczew: just use your favorite editor in the real system in that directory (and there etc/apt/sources.list) [01:38] sistpoty: I don't understand. where's the right file? [01:39] Hey, What is the highest quilt format supported by karmic? [01:39] Daviey: Could you rephrase, or provide more context? [01:39] ari-tczew: pbuilder --login tells me: [01:39] ari-tczew: File extracted to: /var/cache/pbuilder/build//21606 [01:40] ari-tczew: so that would be /var/cache/pbuilder/build/21606/etc/apt/sources.list for me right now [01:40] ahh, okay, I'll check [01:40] 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] 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] I know there are some bugs in 3.0(quilt) that weren't resolved until lucid though. [01:41] * Daviey cries. [01:42] Most people generally downgrade to 1.0: 2.0 has weak support in lots of tools. [01:42] I thought 2.0 never made it? only 3.0? [01:42] sistpoty: 2.0 has some support in some tools in an almost entirely untested way :) [01:43] heh :) [01:43] there does seem to be perl support for 2.0 [01:43] * Daviey is embarrassed to commit http://pastebin.com/d1a11f4f7 [01:48] Daviey: Um, that doesn't accomplish ehat you hope. [01:48] There is no Format: 1.0 (quilt). [01:48] * Daviey cries louder [01:49] 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] yeah, i know that! :o [01:50] Daviey: What are you trying to accomplish? This may be an easier way to solve your issue. [01:50] 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] in pbuilder [01:51] 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] and incidently version 3.0 doesn't auto pop after a debuild.. I sort of expected it to. [01:53] ari-tczew: there's an apt setting to allow untrusted sources, but I've forgotten the details, sorry [01:53] maybe someone else can fix it in pbuilder [01:53] ? [01:53] or you could add the key [01:54] Daviey: Either backport dpkg to the environment you're targeting, or don't switch to Format 3.0 [01:54] 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] persia: yeah, i think backporting is a non-starter because LP PPA will still refuse the karmic package. [01:56] 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] 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] Sleep well :) [01:57] persia: Rejected: [01:57] myththemes_0.23.0~trunk23578-0ubuntu0~mythbuntu1.dsc: format '3.0 (quilt)' is not permitted in karmic. [01:57] geser: pbuilder is calling to my home dir [01:57] and it can't add gpg key [01:58] persia: ^^ that is the PPA email following dput. But i really must sleep. nn [01:58] Daviey: Yeah, I'd call that a bug in launchpad :) [01:58] >:( [01:59] 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] ari-tczew: (inside the pbuilder chroot) [02:01] :O [02:01] ari-tczew: "apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9BDB3D89CE49EC21" inside your pbuilder [02:02] sistpoty: why go the way through "allow unauthenticated" when only the PPA key is missing? [02:08] geser: you've got a point there [02:08] geser: thanks! [04:21] persia: please unsubscribe u-u-s from bug #402874 (restricted), bug #524982 (already ack'd), bug #503111 (uploaded to proposed, awaiting moderation) thanks! [04:21] Launchpad bug 402874 in sl-modem "Sync sl-modem 2.9.11~20090222-3 (restricted) from Debian testing (non-free)" [High,New] https://launchpad.net/bugs/402874 [04:21] Launchpad bug 524982 in frescobaldi "Please sync frescobaldi 1.0.2-1 from Debian unstable/main to universe, ubuntu override ok" [Wishlist,Confirmed] https://launchpad.net/bugs/524982 [04:21] Launchpad bug 503111 in ubuntu-dev-tools "False: The versions in Debian and Ubuntu are the same already during requestsync" [Undecided,Fix committed] https://launchpad.net/bugs/503111 [04:22] persia: or add me to u-u-s, then I can unsubscribe the team, whatever you prefer ;) [04:22] * persia adds [04:23] sistpoty: Welcome to u-u-s. I've also unsubscribed the bugs. [04:23] persia: thanks! [04:23] Down to 10! Wow. [04:24] * persia takes a loot at 507740 and 507741, being related. [04:24] s/ot/ok/ [04:24] * hyperair wonders when he can begin sponsoring things. [04:24] persia: make that 9, just uploading 480553 [04:25] hyperair: If it's not sorted by Tuesday, I'll ask at the TB meeting. [04:25] hyperair: *soon* :) [04:25] yay thanks =) [04:25] * persia wonders if we can clear the queue this weekend [04:25] 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] zooko: 1.6.1 is just a bugfix to 1.6.0 ? [04:26] 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] Launchpad bug 463019 in gtk-recordmydesktop "recordmydesktop does not record frames properly in karmic" [Undecided,In progress] https://launchpad.net/bugs/463019 [04:26] persia: yes [04:26] http://allmydata.org/trac/tahoe-lafs/query?status=assigned&status=new&status=reopened&group=status&milestone=1.6.1 [04:27] 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] Likewise! :-) [04:28] and bug #511864 needs another ack from iulian, nhandler or ScottK [04:28] Launchpad bug 511864 in scilab "FeatureFreezeException: Sync scilab 5.2.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/511864 [04:28] sistpoty: I thought we were going with single-ack from ubuntu-release this cycle? Am I not understanding the mail thread? [04:29] or do I misremember you being a release team member? [04:29] 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] Makes sense. [04:31] 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] persia: for MOTU we've switched to ML w.o. objections actually [04:32] When did that happen? [04:32] imo debdiffs ftw [04:32] Last I knew we had a complicated sheaparding procss. [04:32] persia: some time ago already, let me dig the thread [04:32] 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] persia: what changes were they? [04:33] then upload a debian.tar.gz. simple enough =\ [04:33] hyperair: Actually uploading an orig.tar.gz as part of the package :) [04:33] No, that wouldn't address some classes of thing. [04:33] =\ [04:33] then upload the whole .dsc if necessary [04:33] or stick it up a PPA [04:34] That wouldn't do it either. [04:34] that's what i've been doing [04:34] what wouldn't it address? [04:34] i don't see any more problems [04:34] 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] 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] Plus, it wastes bandwidth. [04:35] persia: and bzr doesn't? === nhandler_ is now known as nhandler [04:35] sistpoty: That's the thread that ended up bringing forward the complicated sheparding process. [04:35] 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] 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] 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] 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] persia: a non new-upstream release sponsor should allow you to get the orig tarball from your local mirror [04:37] 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] which is very much faster than launchpad [04:38] 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] 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] I just don't like having to download the source *twice* to get the orig.tar.gz *and* the bzr branch. [04:39] 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] sabdfl has indicated he'd like to attend the next MOTU meeting, as well. [04:40] 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] Yes, but it was a MOTU meeting that specifically delegated process decision to motu-release. [04:41] But none of this matters, because motu-release is no more (or should be shortly) [04:41] persia: oh, didn't recall that *g* [04:41] Which is a truly good thing, in my opinion :) [04:41] *nod* [04:41] sistpoty: You only came to 1/3 of MOTU meetings :p [04:41] haha [04:42] persia: well if it were maintained i think it would save a lot of bandwidth and time. [04:42] persia: unless launchpad were to get mirrors around the world. [04:42] What? [04:42] persia: the tools that generate packages from diff.gz files [04:43] Not really. It's always faster to use a dsc on a local mirror. [04:43] The tools relied on watch files, get-orig-source rules, etc. [04:43] 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] 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] That makes it show up on u-d-a, and what not. [04:44] 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] 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 === nhandler_ is now known as nhandler [04:48] persia: thanks for taking on the libti* pair. if i've completely botched it, i'm available for punches in the nose. ;-) [04:49] 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] 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] IF you'd like to toss me a couple debdiffs, it'd make it easier for me :) [04:52] 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] That's probably easiest :) [04:52] Well, without merge, I have no idea how I'd get your intended content into the target branch. [04:53] I suppose I could use push --overwrite, but that probably breaks the importer. [04:53] Easier to just do it the old way, which I know works, and let the importer work or break as it likes. [04:53] 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] 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] 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] persia: got it [04:55] sistpoty: We need a couple removals, but kamalmostafa suggests the removals should happen *after* the merges. [04:56] but note... kamalmostafa quite likely is clueless about the proper flow here. :-) that was just my interpretation of ScottK's wishes [04:56] 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] sistpoty: two different source names for the same package, with two entirely different histories. [04:57] persia: ah, then I obviously misread :) [04:57] 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] heh [04:59] 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] 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] 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] 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:05] Ubuntu bug 507741 in libtifiles "libtifiles failed to upload: conflicts with libtifiles2" [Undecided,In progress] [05:08] 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] 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] Doesn't matter at all, and I've disposed of the packages that I used to generate that diff :) [05:14] But I'm a little confused about libtifiles: the upstream version appears to have changed. [05:14] Should I be using the ubuntu libtifiles2 tarball? [05:17] I don't know (again, the actual merge process is quite foreign to me -- you folks always "just take care of it" :-) [05:17] kamalmostafa: OK. Let me ask that differently. What tarball did you use for your local libtifiles package? [05:18] persia: checking here [05:20] 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] OK. Did you build a source package? [05:21] yes [05:21] And there was a tarball as part of that source package? [05:22] certainly -- the orig tarball (maybe this is what you wanted): libtifiles_1.1.1.orig.tar.gz [05:22] 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] 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] Or rather, I can't upload that package. [05:24] 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] 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] but I certainly can't say that I know how we should proceed here [05:25] 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] 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] 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] kamalmostafa: Please tey building a package with the 1.1.2 tarball, and test it, etc. [05:27] s/tey/try/ [05:27] persia: :). I'll have a look at the package branch, shall I? Maybe I'll spot something obvious. [05:28] 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] 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] So you did test against the 1.1.2 tarball? [05:31] Could you pastebin everything but the signature on your source.changes? [05:31] persia: you keep referring to "the ... tarball" -- but remember that I did all of this work using bzr, not tarballs. [05:31] (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] kamalmostafa: Sure, but the source package shouldn't care. The .changes file and .dsc file should be tracking a tarball. [05:32] That you happened to use bzr as a workflow aid should be completely immaterial. [05:32] Otherwise there is a bug in bzr-buildpackage. [05:33] (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] persia: http://pastebin.ubuntu.com/380779/ [05:36] OK. Next bit is tricky: we have to figure out how you constructed libtifiles_1.1.2.orig.tar.gz [05:37] persia: so I actually did all this work like 5 weeks ago, but its all starting to come back to me.... [05:37] Because the checksums don't match the libtifiles2 tarball, and there's no watch file or get-orig-source rule. [05:37] Any ideas? [05:37] I think "bzr builddeb -S" must have constructed it for me. [05:37] (or download it for me) [05:37] Any idea what source it might have used to do so? [05:37] Yes, the "libtifiles2" source [05:38] patched or unpatched? [05:38] ... 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] I don't know the answer to "patched or unpatched". [05:39] Right. [05:39] So, I'm going to disregard that file as locally constructed from unknown sources. [05:40] 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] 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] kamalmostafa: I'm talking about what to use for libtifiles_1.1.2.orig.tar.gz [05:42] 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] So I trust that the libtifiles2 1.1.2 package in the archive has the right tarball. [05:43] Does the content of that tarball match the content of your locally constructed libtifiles_1.1.2.orig.tar.gz ? [05:44] 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] * that it's contents should match then? [05:44] That's my assumption [05:45] 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] 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] kamalmostafa: OK. So, now create and test your package using the upstream tarball, and let me know if it still works. [05:51] I suspect the difference is a call to make clean or similar. [05:51] persia: yes, that's exactly what I am thinking [05:53] 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] 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] 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] 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] Aaah. [05:58] But bzr-buildpackage should still warn users when it *constructs* an artifact and calls it *orig* [05:59] Err, that would have been clearer has I used /constructs/ rather than *constructs* [05:59] s/has/had/ [05:59] * persia gives up [06:00] 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] Well, except I've never experienced it, and don't know how to create a situation where it would occur :) [06:02] I only get annoyed when recommended workflows break trust paths for artifacts. [06:03] 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] kamalmostafa: Do you understand why it matters that I know how to construct your tarball from trusted sources? [06:04] persia: oh yes, certainly! [06:04] (or what I mean by "trusted sources"?) [06:04] Oh, good :) [06:04] oh yes [06:07] 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] bzr: ERROR: Unable to find the needed upstream tarball: libtifiles_1.1.2.orig.tar.gz. [06:07] 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] persia: so no bug to file against bzr, I think. [06:08] Excellent! [06:08] Of course, this doesn't explain how you ended up with the file :) [06:10] *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] Ah, here it is. Yes, I now remember using: bzr builddeb --export-upstream={something} But what was the something? [06:13] 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] 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] persia: okay, forget my comment about --export-upstream. Here's what I did (I can recreate it now): bzr builddeb -S --split [06:21] Hah. Yes. --split generates the orig.tar.gz from the branch. [06:21] what possessed me to use --split? I imagine that it was "Hey, it works! Must be right!" Doh. [06:23] 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] Obviously not enough to have caught my eye. :-( [06:25] There isn't any warning on --split, no. [06:26] 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] 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] “bzr export” would probably be better for them, I think. [06:31] 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] Or `bzr tarball` to combine that with construction and compression in a checksum-safe way. [06:31] 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] 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] 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] kamalmostafa: OK, so we can't upload that :) [06:35] 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] does it belong in the source package at all? [06:36] Due to a decision about how dpkg should work, we can't actually delete anything without breaking the tarball. [06:36] 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] yes, I do remember merging a change to fr.po [06:37] okay, let me see what happens if I dispose of it in clean here. [06:37] Or alternately, we could just not change it. [06:38] you mean leave out the fr.po change? [06:38]